linux-kernel - Re: Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter into memcg)

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]

Message-ID: <20120417151352.GA32402@google.com>
Date:	Tue, 17 Apr 2012 08:13:52 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Johannes Weiner <hannes@...xchg.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Walsh <dwalsh@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Li Zefan <lizefan@...wei.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: Cgroup in a single hierarchy (Was: Re: [RFD] Merge task
 counter into memcg)

Hello, Glauber.

On Thu, Apr 12, 2012 at 02:04:24PM -0300, Glauber Costa wrote:
> 1) Right now, the controllers work independently, and that code will
> have to live for at least some years anyway. So leave it there.
> 
> 2) But also, insert optimization code that can be enabled/disabled
> when companion cgroups are in the same hierarchy.
> 
> 3) After we mount the cgroup, apply those optimization to all of
> them from the cgroup core (the current bind stuff is just way to
> weird for that, IMHO)
> 
> 4) Then we start telling userspace people to favor co-mounts as much
> as they can
> 
> 5) Pray.

Pretty similar to the plan that I was thinking about.

* Provide both mechanisms from the kernel while implementing new
  features / optimizations with the assumption that there's one
  hierarchy.

* Make the switch to single hierarchy from userland, probably by
  implementing a (policy based) userland thing which takes over the
  whole cgroup hierarchy.

* Phase out multiple hierarchy support from kernel slowly.

That said, there are quite a few obstacles including being able to
support most (probably not all) use cases possible under multiple
hierarchies and managing the added complexity over the transition
period.  I don't think it's gonna be easy.  Needs more thinking.

Thanks.

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