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
| ||
|
Message-ID: <472256AB.6060109@mbligh.org> Date: Fri, 26 Oct 2007 14:05:47 -0700 From: Martin Bligh <mbligh@...igh.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Marcelo Tosatti <marcelo@...ck.org>, linux-kernel@...r.kernel.org, drepper@...hat.com, riel@...hat.com, linux-mm@...ck.org Subject: Re: OOM notifications Andrew Morton wrote: > On Thu, 18 Oct 2007 16:15:31 -0400 > Marcelo Tosatti <marcelo@...ck.org> wrote: > >> Hi, >> >> AIX contains the SIGDANGER signal to notify applications to free up some >> unused cached memory: >> >> http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html >> >> There have been a few discussions on implementing such an idea on Linux, >> but nothing concrete has been achieved. >> >> On the kernel side Rik suggested two notification points: "about to >> swap" (for desktop scenarios) and "about to OOM" (for embedded-like >> scenarios). >> >> With that assumption in mind it would be necessary to either have two >> special devices for notification, or somehow indicate both events >> through the same file descriptor. >> >> Comments are more than welcome. > > Martin was talking about some mad scheme wherin you'd create a bunch of > pseudo files (say, /proc/foo/0, /proc/foo/1, ..., /proc/foo/9) and each one > would become "ready" when the MM scanning priority reaches 10%, 20%, ... > 100%. > > Obviously there would need to be a lot of abstraction to unhook a permanent > userspace feature from a transient kernel implementation, but the basic > idea is that a process which wants to know when the VM is getting into the > orange zone would select() on the file "7" and a process which wants to > know when the VM is getting into the red zone would select on file "9". > > It get more complicated with NUMA memory nodes and cgroup memory > controllers. We ended up not doing that, but making a scanner that saw what percentage of the LRU was touched in the last n seconds, and printing that to userspace to deal with. Turns out priority is a horrible metric to use for this - it stays at default for ages, then falls off a cliff far too quickly to react to. - 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