Re: [PATCH] control groups: documentation improvements

[Glyn Normington]

Hi Tejun

Stepping back from the patch for a while, we'd like to explore the issues you raise. Please bear with us as we try to capture the ideas precisely.

Continued inline...

Regards,
Glyn (& Steve Powell, copied)

On 10/03/2014 14:20, Tejun Heo wrote:
> Hey,
>
> On Mon, Mar 10, 2014 at 02:17:21PM +0000, Glyn Normington wrote:
> > Then we missed how to create a hierarchy with no associated
> > subsystems. The only way I can think of is to use mount, specify no
> > subsystems on -o (which defaults to all the subsystems defined in
> > the kernel), and run it in a kernel with no subsystems defined
> > (which seems unlikely these days).
> >
> > Is that what you had in mind or is there some other way of creating
> > a hierarchy with no subsystems attached?
> Hierarchy name should be specified "-o name=" for hierarchies w/o any
> controllers.

According to cgroups.txt:

 When passing a name=<x> option for a new hierarchy, you need to
 specify subsystems manually; the legacy behaviour of mounting all
 subsystems when none are explicitly specified is not supported when
 you give a subsystem a name.

So the documentation certainly does not make it clear that it is valid to specify no subsystems.

We tried this (on a 3.11 kernel) and can't get it to work:

# mount -t cgroup -o name=th none /home/glyn/h1

mount: wrong fs type, bad option, bad superblock on none,
    missing codepage or helper program, or other error
    (for several filesystems (e.g. nfs, cifs) you might
    need a /sbin/mount.<type> helper program) In some
    cases useful info is found in syslog - try dmesg |
    tail or so

Please could you supply an example which works?

> > > > Clarify that subsystems may be attached to multiple hierarchies,
> > > > although this isn't very useful, and explain what happens.
> > > And a subsystem may only be attached to a single hierarchy.
> > Perhaps that's what should happen, but the following experiment
> > demonstrates a subsystem being attached to two hierarchies:
> >
> > $ pwd
> > /home/vagrant
> > $ mkdir mem1
> > $ mkdir mem2
> > $ sudo su
> > # mount -t cgroup -o memory none /home/vagrant/mem1
> > # mount -t cgroup -o memory none /home/vagrant/mem2
> > # cd mem1
> > # mkdir inst1
> > # ls inst1
> > cgroup.clone_children  memory.failcnt ...
> > # ls ../mem2
> > cgroup.clone_children  inst1 memory.limit_in_bytes ...
> > # cd inst1
> > # echo 1000000 > memory.limit_in_bytes
> > # cat memory.limit_in_bytes
> > 1003520
> > # cat ../../mem2/inst1/memory.limit_in_bytes
> > 1003520
> > # echo $$ > tasks
> > # cat tasks
> > 1365
> > 1409
> > # cat ../../mem2/inst1/tasks
> > 1365
> > 1411
> You're mounting the same hierarchy twice.  Those are two views into
> the same hierarchy.
>
> Thanks.
Yes, it does appear that this is what is going on, but to explain it this way turns out to be more complicated than one might expect. Here's an attempt...

---
 A*hierarchy*  is a non-empty set of cgroups arranged in a tree and a
 non-empty set of subsystems such that the cgroups in the hierarchy
 partition all the tasks in the system (in other words, every task in the
 system is in exactly one of the cgroups in the hierarchy) and each
 subsystem attaches its own state to each cgroup in the hierarchy.

 There may be zero or more active hierarchies. Each hierarchy has one
 or more views associated with it. A *view* is an instance of the cgroup
 virtual filesystem. The tree of cgroups of a hierarchy is represented
 by the directory tree in the cgroup virtual filesystem of each view of
 the hierarchy. All the directory trees in the cgroup virtual filesystem
 of the views of a given hierarchy have identical content.

 No subsystem may participate in more than one hierarchy.
---

We'd also need to explain the behaviour of mount and umount with respect to views. The first time a cgroup mount is performed with a given set of subsystems, a hierarchy is created and a view of the hierarchy is created and associated with a cgroup filesystem at the mount point. Subsequently, if another cgroup mount is performed with the same set of subsystems, no new hierarchy is created but a new view of the existing hierarchy is created and associated with the cgroup filesystem at the new mount point.

Unmounting a cgroup mount point destroys a particular view and destroys the hierarchy associated with the view if and only if the view is the only (remaining) view of the hierarchy.

So does introducing the concept of a view really help? The wording in the patch does without the concept by allowing two "hierarchies" to have identical content (so they are indistinguishable).

"views" don't seem to have any practical benefit. If we can avoid explaining concepts which have no use, we probably should. ;-)


--
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/