linux-kernel - Re: [PATCH v2 1/3] cgroup: define controller file conventions

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] [day] [month] [year] [list]

Date:	Tue, 18 Aug 2015 00:04:48 +0200
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Tejun Heo <tj@...nel.org>, mingo@...hat.com,
	peterz@...radead.org, lizefan@...wei.com, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH v2 1/3] cgroup: define controller file conventions

On Fri, Aug 07, 2015 at 08:17:23PM +0200, Michal Hocko wrote:
> On Thu 06-08-15 11:30:08, KAMEZAWA Hiroyuki wrote:
> >  - *.oom_control      - for surviving/notifiyng out of memory
> >                         memcg's oom can be recovered if limit goes up rather than kill.
> 
> I think it is very much useful - when used wisely. I have seen many
> calls for user defined OOM policies but then we have seen those that are
> more creative like having the policy maker live in the same memcg which
> requires some hacks to prevent from self-deadlocks.
> So overall this is very attractive but we might need to think about a
> better interface. BPF sounds like a potential way to go. I feel the
> memcg and the global approaches should be consistent as much as possible
> wrt. API.

I'm not sure I still see a usecase for this.

The whole idea behind memory.high is to give the user the chance to
monitor the group's health and then act upon that. You can freeze the
group if you must, gather information, kill tasks. This is the way to
implement a custom OOM policy.

memory.max on the other hand tells the *kernel* when to OOM, with all
the implications that a kernel OOM has. Don't configure that when you
don't want your tasks killed.
--
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/