From: Eric W. Biederman <hidden> Date: 2015-01-07 23:30:49
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:
Tejun Heo [off-list ref] writes:
quoted
On Wed, Jan 07, 2015 at 05:02:17PM -0600, Eric W. Biederman wrote:
quoted
Ignoring namespace details for a moment. The following should be
possible with a unified hierarchy. If it is not it is a show stopper
of a regression.
The -o SUBSYS option doesn't exist. Jesus, at least get yourself
familiar with the basics before claiming random stuff.
Oh let's see I got that command line option out of /proc/mounts and yes
it works. Perhaps it doesn't if I invoke unified hiearchies but the
option does in fact exist and work.
Now I really do need to test report regressions, and send probably send
regression fixes. If I understand your strange ranting I think you just
told me that option that -o SUBSYS does work with unified hierarchies.
Tejun. I asked you specifically about this case 2 years ago at plumbers
and you personally told me this would continue to work. I am going to
hold you to that.
Fixing bugs is one thing. Gratuitious regressions that make supporting
existing user space applications insane is another.
Eric
On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote:
quoted
quoted
The -o SUBSYS option doesn't exist. Jesus, at least get yourself
familiar with the basics before claiming random stuff.
Oh let's see I got that command line option out of /proc/mounts and yes
it works. Perhaps it doesn't if I invoke unified hiearchies but the
option does in fact exist and work.
I meant the -o SUBSYS doesn't exist for unified hierarchy.
Now I really do need to test report regressions, and send probably send
regression fixes. If I understand your strange ranting I think you just
told me that option that -o SUBSYS does work with unified hierarchies.
What? Why would -O SUBSYS exist for unified hierarchy? It's unified
for all controllers.
Tejun. I asked you specifically about this case 2 years ago at plumbers
and you personally told me this would continue to work. I am going to
hold you to that.
I have no idea what you're talking about in *THIS* thread. I'm fully
aware of what was discussed *THEN*.
Fixing bugs is one thing. Gratuitious regressions that make supporting
existing user space applications insane is another.
Can you explain what problem you're actually trying to talk about
without spouting random claims about regressions?
--
tejun
On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote:
quoted
quoted
quoted
The -o SUBSYS option doesn't exist. Jesus, at least get yourself
familiar with the basics before claiming random stuff.
Oh let's see I got that command line option out of /proc/mounts and yes
it works. Perhaps it doesn't if I invoke unified hiearchies but the
option does in fact exist and work.
I meant the -o SUBSYS doesn't exist for unified hierarchy.
quoted
Now I really do need to test report regressions, and send probably send
regression fixes. If I understand your strange ranting I think you just
told me that option that -o SUBSYS does work with unified hierarchies.
What? Why would -O SUBSYS exist for unified hierarchy? It's unified
for all controllers.
quoted
Tejun. I asked you specifically about this case 2 years ago at plumbers
and you personally told me this would continue to work. I am going to
hold you to that.
I have no idea what you're talking about in *THIS* thread. I'm fully
aware of what was discussed *THEN*.
quoted
Fixing bugs is one thing. Gratuitious regressions that make supporting
existing user space applications insane is another.
Can you explain what problem you're actually trying to talk about
without spouting random claims about regressions?
A few weeks ago, in order to test the cgroup namespace patchset with lxc,
I went through the motions of getting lxc to work with unified hierarchy.
A few of the things I had to change:
1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
to start with 1. I expect many userspace parsers to be broken by this.
2. After creating every non-leaf cgroup, we must fill in the
cgroup.subtree_cgroups file. This is extra work which userspace
doesn't have to do right now.
3. Let's say we want to create a freezer cgroup /foo/bar for some set of
tasks, which they will administer. In fact let's assume we are going to
use cgroup namespaces. We have to put the tasks into /foo/bar, unshare
the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf,
and then write 'freezer' into /foo/bar. (If we're not using cgroup
namespaces, then we have to do a similar thing to let the tasks administer
/foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing
to is where the tasks have to know that they can create cgroups in "..".
For containers this becomes odd. We tend to group containers by the
tasks in and under a cgroup. We now will have to assume a convention
where we know to check for tasks in and under "..", since by definition
pid 1's cgroup (in a container) cannot have children.
4. The per-cgroup "tasks" file not existing seems odd, although certainly
unexpected by much current software.
So, if the unified hierarchy is going to not cause undue pain, existing
software really needs to start working now to use it. It's going to be
a sizeable task for lxc.
-serge
On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote:
1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
to start with 1. I expect many userspace parsers to be broken by this.
This is intentional. The unified hierarchy will always have the
hierarchy number zero. Userland needs to be updated anyway and the
unified hierarchy won't show up unless explicitly enabled.
2. After creating every non-leaf cgroup, we must fill in the
cgroup.subtree_cgroups file. This is extra work which userspace
doesn't have to do right now.
Again, by design. This is how organization and control are separated
and the differing levels of granularity is achieved.
3. Let's say we want to create a freezer cgroup /foo/bar for some set of
There shouldn't be a "freezer" cgroup. The processes are categorized
according to their logical structure and controllers are applied to
the hierarchy as necessary.
tasks, which they will administer. In fact let's assume we are going to
use cgroup namespaces. We have to put the tasks into /foo/bar, unshare
the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf,
and then write 'freezer' into /foo/bar. (If we're not using cgroup
namespaces, then we have to do a similar thing to let the tasks administer
/foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing
to is where the tasks have to know that they can create cgroups in "..".
For containers this becomes odd. We tend to group containers by the
tasks in and under a cgroup. We now will have to assume a convention
where we know to check for tasks in and under "..", since by definition
pid 1's cgroup (in a container) cannot have children.
The semantics is that the parent enables distribution of its given
type of resource by enabling the controller in its subtree_control.
This scoping isn't necessary for freezer and I'm debating whether to
enable controllers which don't need granularity control to be enabled
unconditionally. Right now, I'm leaning against it mostly for
consistency.
4. The per-cgroup "tasks" file not existing seems odd, although certainly
unexpected by much current software.
And, yes, everything is per-process for reasons described in
unified-hierarchy.txt.
So, if the unified hierarchy is going to not cause undue pain, existing
software really needs to start working now to use it. It's going to be
a sizeable task for lxc.
Yes, this isn't gonna be a trivial conversion. The usage model
changes and so will a lot of controller knobs and behaviors.
Thanks.
--
tejun
On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote:
quoted
1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
to start with 1. I expect many userspace parsers to be broken by this.
This is intentional. The unified hierarchy will always have the
hierarchy number zero. Userland needs to be updated anyway and the
unified hierarchy won't show up unless explicitly enabled.
quoted
2. After creating every non-leaf cgroup, we must fill in the
cgroup.subtree_cgroups file. This is extra work which userspace
doesn't have to do right now.
Again, by design. This is how organization and control are separated
and the differing levels of granularity is achieved.
quoted
3. Let's say we want to create a freezer cgroup /foo/bar for some set of
There shouldn't be a "freezer" cgroup. The processes are categorized
according to their logical structure and controllers are applied to
the hierarchy as necessary.
But there can well be cgroups for which only freezer is enabled. If
I'm wrong about that, then I am suffering a fundamental misunderstanding.
quoted
tasks, which they will administer. In fact let's assume we are going to
use cgroup namespaces. We have to put the tasks into /foo/bar, unshare
the cgroup ns, then create /foo/bar/leaf, move the tasks into /foo/bar/leaf,
and then write 'freezer' into /foo/bar. (If we're not using cgroup
namespaces, then we have to do a similar thing to let the tasks administer
/foo/bar while placing them under /foo/bar/leaf). The oddness I'm pointing
to is where the tasks have to know that they can create cgroups in "..".
For containers this becomes odd. We tend to group containers by the
tasks in and under a cgroup. We now will have to assume a convention
where we know to check for tasks in and under "..", since by definition
pid 1's cgroup (in a container) cannot have children.
The semantics is that the parent enables distribution of its given
type of resource by enabling the controller in its subtree_control.
This scoping isn't necessary for freezer and I'm debating whether to
enable controllers which don't need granularity control to be enabled
unconditionally. Right now, I'm leaning against it mostly for
consistency.
Yeah, IIUC (i.e. freezer would always be enabled?) that would be
even-more-confusing.
quoted
4. The per-cgroup "tasks" file not existing seems odd, although certainly
unexpected by much current software.
And, yes, everything is per-process for reasons described in
unified-hierarchy.txt.
quoted
So, if the unified hierarchy is going to not cause undue pain, existing
software really needs to start working now to use it. It's going to be
a sizeable task for lxc.
Yes, this isn't gonna be a trivial conversion. The usage model
changes and so will a lot of controller knobs and behaviors.
Thanks.
--
tejun
Hello,
On Wed, Feb 11, 2015 at 05:29:42AM +0100, Serge E. Hallyn wrote:
quoted
There shouldn't be a "freezer" cgroup. The processes are categorized
according to their logical structure and controllers are applied to
the hierarchy as necessary.
But there can well be cgroups for which only freezer is enabled. If
I'm wrong about that, then I am suffering a fundamental misunderstanding.
Ah, sure, I was mostly arguing semantics. It's just weird to call it
"freezer" cgroup.
quoted
The semantics is that the parent enables distribution of its given
type of resource by enabling the controller in its subtree_control.
This scoping isn't necessary for freezer and I'm debating whether to
enable controllers which don't need granularity control to be enabled
unconditionally. Right now, I'm leaning against it mostly for
consistency.
Yeah, IIUC (i.e. freezer would always be enabled?) that would be
even-more-confusing.
Right, freezer is kinda weird tho. Its feature can almost be
considered a utility feature of cgroups core rather than a separate
controller. That said, it's most likely that it'll remain in its
current form although how it blocks tasks should definitely be
reimplemented.
Thanks.
--
tejun