[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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    [W:0.020 / U:10.172 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site