lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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