linux-kernel - Re: user defined OOM policies

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, 2 Dec 2013 15:07:39 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...e.cz>
cc:	linux-mm@...ck.org, Greg Thelen <gthelen@...gle.com>,
	Glauber Costa <glommer@...il.com>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>,
	Joern Engel <joern@...fs.org>, Hugh Dickins <hughd@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: user defined OOM policies

On Thu, 28 Nov 2013, Michal Hocko wrote:

> > Agreed, and I think the big downside of doing it with the loadable module 
> > suggestion is that you can't implement such a wide variety of different 
> > policies in modules.  Each of our users who own a memcg tree on our 
> > systems may want to have their own policy and they can't load a module at 
> > runtime or ship with the kernel.
> 
> But those users care about their local (memcg) OOM, don't they? So they
> do not need any module and all they want is to get a notification.

Sure, but I think the question is more of the benefit of doing it in the 
kernel as opposed to userspace.  If we implement the necessary mechanisms 
that allow userspace to reliably handle these situations, I don't see much 
of a benefit to modules other than for separating code amongst multiple 
files in the source.  I don't think we want to ship multiple different oom 
policies because then userspace that cares about it has to figure out 
what's in effect and what it can do with what's available.  I'd argue that 
a the key functionality that I've already described (system oom 
notification, memcg reserves, timeout) allow for any policy to be defined 
reliably in userspace.
--
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/