linux-kernel - RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Jan 2012 12:55:06 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
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, penberg@...nel.org, aarcange@...hat.com,
	riel@...hat.com, mel@....ul.ie, dima@...roid.com,
	rebecca@...roid.com, san@...gle.com, akpm@...ux-foundation.org,
	vesa.jaaskelainen@...ia.com
Subject: RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

On Mon, 9 Jan 2012, leonid.moiseichuk@...ia.com wrote:

> > I'm not sure why you need to detect low memory thresholds if you're not
> > interested in using the memory controller, why not just use the oom killer
> > delay that I suggested earlier and allow userspace to respond to conditions
> > when you are known to failed reclaim and require that something be killed?
> 
> As I understand that is required to turn on memcg and memcg is a thing 
> I try to avoid.
> 

Maybe there's some confusion: the proposed oom killer delay that I'm 
referring to here is not upstream and has never been written for global 
oom conditions.  My reference to it earlier was as an internal patch that 
we carry on top of memory controller, but what I'm proposing here is for 
it to be implemented globally.

So if the page allocator can make no progress in freeing memory, we would 
introduce a delay in out_of_memory() if it were configured via a sysctl 
from userspace.  When this delay is started, applications waiting on this 
event can be notified with eventfd(2) that the delay has started and they 
have however many milliseconds to address the situation.  When they 
rewrite the sysctl, the delay is cleared.  If they don't rewrite the 
sysctl and the delay expires, the oom killer proceeds with killing.

What's missing for your usecase with this proposal?
--
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/