From: Serge Hallyn <serge.hallyn@canonical.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
containers@lists.linux-foundation.org,
Kay Sievers <kay.sievers@vrfy.org>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Lennart Poettering <lennart@poettering.net>,
cgroups@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFD] cgroup: about multiple hierarchies
Date: Sat, 3 Mar 2012 08:26:04 -0600 [thread overview]
Message-ID: <20120303142604.GA13187@peqn> (raw)
In-Reply-To: <m162em2efy.fsf@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> 4. Only allow a single controller per hierarchy. So that we can
> make reasonable choice points. If the hierarchy is to be about
> policy I am baffled by concept of putting multiple controllers in
> a single hierarchy. Because where you clump things together for
> policy for one controller in general does not seem to be where you
> want to clump things together for another controller.
This I agree with. The only reasonably use I've seen for the
composed hierarchies is the ns cgroup, which was the wrong tool
for what it wanted to do anyway. With ns cgroup deprecated, every
modern setup I've seen mounts each cgroup separately.
> > So, I mean, I don't know. What do other people think? Is this a
> > unnecessary worry? Are people generally happy with the way things
> > are? Lennart, Kay, what do you guys think?
>
> I think the current situation is crazy.
>
> I especially think it is crazy that inside a container I can't create
> a fresh set of cgroup mounts, and establish a fresh "hierarchy" relative
> to the process that created the cgroup mounts. It sucks that
> controllers may nest fine but hierarchies don't nest.
Again I agree here. In the past there has been brought up the idea
of fake cgroup roots ( http://thread.gmane.org/gmane.linux.kernel/1197643 )
I haven't looked in detail, but I know some people hated this particular
idea. But it tried to solve this problem.
Perhaps we can attack this in two stages.
1. get rid of the ability to compose cgroups. See how much this
simplifies the code.
2. add the ability to somehow namespace the cgroup mounts to allow a
container to freshly mount cgroups.
-serge
next prev parent reply other threads:[~2012-03-03 14:26 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 21:19 [RFD] cgroup: about multiple hierarchies Tejun Heo
2012-02-21 21:21 ` Tejun Heo
2012-02-22 13:34 ` Glauber Costa
2012-02-23 7:45 ` Serge E. Hallyn
2012-02-23 17:29 ` Tejun Heo
2012-02-23 18:47 ` Serge Hallyn
2012-02-26 4:59 ` Konstantin Khlebnikov
2012-02-22 13:30 ` Peter Zijlstra
2012-02-22 13:37 ` Glauber Costa
2012-02-22 18:01 ` Tejun Heo
2012-02-23 7:39 ` Li Zefan
2012-02-22 15:45 ` Frederic Weisbecker
2012-02-22 18:22 ` Tejun Heo
2012-02-27 17:46 ` Frederic Weisbecker
2012-02-22 16:38 ` Vivek Goyal
2012-02-22 16:57 ` Vivek Goyal
2012-02-22 18:43 ` Tejun Heo
2012-02-23 9:41 ` Peter Zijlstra
2012-02-23 14:13 ` Peter Zijlstra
2012-03-01 17:19 ` Michal Schmidt
2012-03-01 18:03 ` Peter Zijlstra
2012-03-02 11:08 ` Michal Schmidt
2012-03-02 11:23 ` Peter Zijlstra
2012-03-02 11:28 ` Michal Schmidt
2012-03-02 11:34 ` Peter Zijlstra
2012-03-01 20:26 ` Mike Galbraith
2012-03-01 21:02 ` Vivek Goyal
2012-03-01 22:04 ` Mike Galbraith
2012-03-01 22:38 ` C Anthony Risinger
2012-03-02 10:51 ` Michal Schmidt
2012-03-02 11:52 ` Mike Galbraith
2012-03-05 12:43 ` Lennart Poettering
2012-03-05 15:47 ` Mike Galbraith
2012-03-05 19:58 ` Mike Galbraith
2012-03-02 2:43 ` Kay Sievers
2012-03-02 10:15 ` Peter Zijlstra
2012-03-02 11:16 ` Michal Schmidt
2012-03-02 11:24 ` Peter Zijlstra
2012-02-23 21:38 ` Vivek Goyal
2012-02-23 22:34 ` Tejun Heo
2012-02-28 21:16 ` Vivek Goyal
2012-02-28 21:21 ` Peter Zijlstra
2012-02-28 21:35 ` Vivek Goyal
2012-02-28 21:43 ` Peter Zijlstra
2012-02-28 21:54 ` Vivek Goyal
2012-02-28 22:00 ` Peter Zijlstra
2012-02-28 22:31 ` Vivek Goyal
2012-02-28 21:53 ` Peter Zijlstra
2012-02-28 22:09 ` Vivek Goyal
2012-02-24 11:33 ` Peter Zijlstra
2012-02-22 18:33 ` Tejun Heo
2012-02-23 19:41 ` Vivek Goyal
2012-02-23 22:38 ` Tejun Heo
2012-02-23 7:59 ` Li Zefan
2012-02-23 20:32 ` Vivek Goyal
2012-02-23 8:22 ` Li Zefan
2012-02-23 17:33 ` Tejun Heo
[not found] ` <m162em2efy.fsf@fess.ebiederm.org>
2012-03-03 14:26 ` Serge Hallyn [this message]
2012-03-05 11:37 ` Lennart Poettering
2012-03-12 22:10 ` Tejun Heo
2012-03-12 22:22 ` Peter Zijlstra
2012-03-12 22:28 ` Tejun Heo
2012-03-12 22:31 ` Lennart Poettering
2012-03-12 23:00 ` Tejun Heo
2012-03-12 23:02 ` Peter Zijlstra
2012-03-12 23:09 ` Tejun Heo
2012-03-12 23:43 ` Lennart Poettering
2012-03-12 22:32 ` Peter Zijlstra
2012-03-12 22:39 ` Tejun Heo
2012-03-12 22:44 ` Peter Zijlstra
2012-03-12 23:04 ` Tejun Heo
2012-03-13 14:10 ` Vivek Goyal
2012-03-13 16:11 ` C Anthony Risinger
2012-03-13 16:30 ` C Anthony Risinger
2012-03-13 17:25 ` Peter Zijlstra
2012-03-13 17:31 ` Peter Zijlstra
2012-03-13 10:11 ` Glauber Costa
2012-03-13 14:03 ` Vivek Goyal
2012-03-13 15:59 ` Tejun Heo
2012-03-16 23:14 ` James Bottomley
2012-03-12 22:37 ` Serge Hallyn
2012-03-12 22:55 ` Tejun Heo
2012-03-13 13:49 ` Vivek Goyal
2012-03-13 16:02 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120303142604.GA13187@peqn \
--to=serge.hallyn@canonical.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=kay.sievers@vrfy.org \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).