[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOJsxLEdTMB6JtYViRJq5gZ4_w5aaV18S3q-1rOXGzaMtmiW6A@mail.gmail.com>
Date: Thu, 5 Jan 2012 14:40:49 +0200
From: Pekka Enberg <penberg@...nel.org>
To: leonid.moiseichuk@...ia.com
Cc: gregkh@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
cesarb@...arb.net, kamezawa.hiroyu@...fujitsu.com,
emunson@...bm.net, aarcange@...hat.com, riel@...hat.com,
mel@....ul.ie, rientjes@...gle.com, dima@...roid.com,
rebecca@...roid.com, san@...gle.com, akpm@...ux-foundation.org,
vesa.jaaskelainen@...ia.com
Subject: Re: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related
changes in MM
On Thu, Jan 5, 2012 at 1:47 PM, <leonid.moiseichuk@...ia.com> wrote:
> As I understand AOOM it wait until situation is reached bad conditions which
> required memory reclaiming, selects application according to free memory and
> oom_adj level and kills it. So no intermediate levels could be checked (e.g.
> 75% usage), nothing could be done in user-space to prevent killing, no
> notification for case when memory becomes OK.
>
> What I try to do is to get notification in any application that memory
> becomes low, and do something about it like stop processing data, close
> unused pages or correctly shuts applications, daemons. Application(s) might
> have necessity to install several notification levels, so reaction could be
> adjusted based on current utilization level per each application, not
> globally.
Sure. However, from VM point of view, both have the exact same
functionality: detect when we reach low memory condition (for some
configurable threshold) and notify userspace or kernel subsystem about
it.
That's the part I'd like to see implemented in mm/notify.c or similar.
I really don't care what Android or any other folks use it for exactly
as long as the generic code is light-weight, clean, and we can
reasonably assume that distros can actually enable it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists