linux-kernel - 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]

Date:	Thu, 12 Apr 2012 14:04:24 -0300
From:	Glauber Costa <glommer@...allels.com>
To:	Tejun Heo <tj@...nel.org>
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: Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter into
 memcg)

On 04/12/2012 01:38 PM, Tejun Heo wrote:
> Hello, Johannes.
>
> On Thu, Apr 12, 2012 at 05:30:55PM +0200, Johannes Weiner wrote:
>>> But also, I believe this has been widely discussed in person by
>>> people, in separate groups. Maybe Tejun can do a small writeup of
>>> where we stand?
>
> I'm still mulling over it.  What I want is single hierarchy with more
> unified rules regarding how different controllers handle the hierarchy
> in such way that different controllers may interact - ie. memcg and
> blkio can share the same page tags, or cgroup-freezer can provide
> freezing service to other controllers.  I want if a task belongs to
> cgroup, it belongs to _the_ cgroup and you can figure out all cgroup
> related stuff from there.

Agreed.
If you would allow me to side track (I'll answer the rest of the e-mail 
separately to avoid confusion)

One of the things I attempted in cpu/cpuacct, is to patch in code with 
static_branches when they are comounted. I so far temporarily failed 
because some locking order rules, and could not yet go back to that.

But we could do something more general, that could work at least until
we actually finally finish whatever rework we're doing.

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.

Of course this is a sketch, but what do you think?
--
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/