lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.


\
 
 \ /
  Last update: 2009-01-15 08:59    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site