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:	Wed, 11 Jan 2012 12:46:33 +0000
From:	<leonid.moiseichuk@...ia.com>
To:	<rientjes@...gle.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

> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@...gle.com]
> Sent: 09 January, 2012 21:55
...
> 
> 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.

That is explains situation - I know how memcg can handle OOM in cgroup but not about internal patch.

> 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 use case with this proposal?

Timed delays in multi-process handling in case OOM looks for me fragile construction due to delays are not predicable.
Memcg supports [1] better approach to freeze whole group and kick pointed user-space application to handle it. We planned
to use it as:
- enlarge cgroup
- send SIGTERM to selected "bad" application e.g. based on oom_score
- wait a bit
- send SIGKILL to "bad" application
- reduce group size

But finally default OOM killer starts to work fine.

[1] http://lwn.net/Articles/377708/

 
--
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/