Messages in this thread | | | Date | Wed, 14 Jan 2009 23:55:54 -0800 (PST) | From | David Rientjes <> | Subject | Re: lowmemory android driver not needed? |
| |
On Wed, 14 Jan 2009, Alan Cox wrote:
> I was thinking that, and it would integrate better with the OLPC work > (which IMHO is a nicer interface for some stuff) > > You'd want two thresholds > > The 'arghhhh....' point where you start killing stuff > The 'uh oh...' point where an OLPC style low memory notifier kicks in > > (OLPC's model is a handle you can select/poll for 'memory getting low' so > apps can respond to pressure by doing stuff like dumping caches) > > The rest ought to follow naturally IFF you can find a clean efficient way > to measure that pressure and quantify it as a number. Our default would > be like now, the Android default might be to trigger earlier..
The /dev/mem_notify patch allowed polling on a system-wide scale for low memory conditions so that userspace could respond appropriately: either by droping caches, as you mentioned, or sending a signal. That signal could quite possibily be SIGKILL for no better reason than preempting what the kernel oom killer would do.
I think this should be completely seperate from the oom killer, which has always been a "last resort" to situations where the kernel is completely out of memory for a task.
If /dev/mem_notify existed in a cgroup form so that different handlers could be responsible for an aggregate of tasks, I think this addresses your concerns. That might require some cleverness in the cgroup filesystem code if this would introduce device files, but there are probably future use cases for that, as well.
| |