Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces
From: Serge E. Hallyn
Date: Tue Feb 10 2015 - 23:29:52 EST
Quoting Tejun Heo (tj@xxxxxxxxxx):
> 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.
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.
> > 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
Yeah, IIUC (i.e. freezer would always be enabled?) that would be
> > 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
> > 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/