linux-kernel - Re: [RFD] cgroup: about multiple hierarchies

Open Source and information security mailing list archives

Message-ID: <20120312223707.GA8272@peqn>
Date:	Mon, 12 Mar 2012 17:37:07 -0500
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
	Michal Schmidt <mschmidt@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org,
	Lennart Poettering <lennart@...ttering.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFD] cgroup: about multiple hierarchies

Quoting Tejun Heo (tj@...nel.org):
> Hello, guys.
> 
> Thanks a lot for the discussion and here are my take aways:
> 
> * At least to me, nobody seems to have strong enough justification for
>   orthogonal multiple hierarchies, so, yeah, unless something else

First off, can you (sorry) show an example of exactly what would no
longer be supported?  Is this the ability to not separately mount
freezer and cpusets (for instance)?

I've submitted a topic for the upcoming linux foundation end user summit
in new york, to get feedback from end users.  (Frankly I don't want to go
so would love if someone else wanted to do this :).  I think it'd be nice
to wait and see if this gets accepted, and see whether any end users are
relying on this.

(IMO it's wrong to say that "if you are using a current feature, you'd
better be reading lkml so you can speak up lest that feature might get
removed.")

>   happens, I'm scheduling multiple hierarchy support for the chopping
>   block.  This is a long term thing (think years), so no need to panic
>   right now and as is life plans may change and fail to materialize,
>   but I intend to at least move away from it.
> 
> * Several people pointed out that it would be inconvenient to require
>   cgroup hierarchy to be a strict super-imposed tree on top of process
>   tree and that program groups / sessions aren't like that either.  I
>   agree, so it will hopefully be single hierarchy which more or less
>   behaves the same as the current hierarchy.
> 
> * How to map controllers which aren't aware of full hierarchy is still
>   an open question but I'm still standing by one active node on any
>   root-to-leaf path w/ root group serving as the special rest group.
> 
>   This should happen first for the long migration to begin.  I might
>   get to it someday but if anyone can beat me to it, please go ahead.
>   I'll be ecstatic to review and merge the patches.
> 
> Also, I'll slowly be marking features which don't seem essential,
> especially the convenience features for multiple hierarchies, as
> deprecated and eventually chop them.
> 
> Thank you.
> 
> -- 
> tejun
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
--
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/

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