linux-kernel - Re: [RFC] [PATCH] Cgroup based OOM killer controller

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:	Thu, 22 Jan 2009 00:43:38 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Nikanth Karthikesan <knikanth@...e.de>
cc:	Evgeniy Polyakov <zbr@...emap.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chris Snook <csnook@...hat.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Paul Menage <menage@...gle.com>,
	containers@...ts.linux-foundation.org
Subject: Re: [RFC] [PATCH] Cgroup based OOM killer controller

On Thu, 22 Jan 2009, Nikanth Karthikesan wrote:

> No, this is not specific to memcg or cpuset cases alone. The same needless 
> kills will take place even without memcg or cpuset when an administrator 
> specifies a light memory consumer to be killed before a heavy memory user. But 
> it is up to the administrator to use it wisely.

You can't specify different behavior for an oom cgroup depending on what 
type of oom it is, which is the problem with this proposal.

For example, if your task triggers an oom as the result of its exclusive 
cpuset placement, the oom killer should prefer to kill a task within that 
cpuset to allow for future memory freeing.

So, with your proposal, an administrator can specify the oom priority of 
an entire aggregate of tasks but the behavior may not be desired for a 
cpuset-constrained oom, while it may be perfectly legitimate for a global 
unconstrained oom.

I can specify a higher oom priority for a cpuset because its jobs are less 
critical and I would prefer it gets killed in a system-wide oom, but any 
other cpuset that ooms will needlessly kill these tasks when there is no 
benefit.

> We also provide a panic_on_oom 
> option that an administrator could use, not just to kill few more tasks but 
> all tasks in the system ;)
> 

panic_on_oom allows you to specify whether you want to panic on any oom or 
on global non-constrained ooms, as well.  When the sysctl is not set to 2, 
it is a no-op in a cpuset, mempolicy, or memcg oom condition.
--
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/