Re: [PATCH] control groups: documentation improvements

[Glyn Normington]

Hi Li

Thanks! Inline...

Tejun: Li agrees with our reasoning on the "views" issue, but we'd like 
your feedback too in preparation for a new patch.

Regards,
Glyn & Steve
On 14/03/2014 01:33, Li Zefan wrote:
> On 2014/3/14 0:04, Glyn Normington wrote:
> > 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 -t cgroup -o name=th,none none /home/glyn/h1
Great! We'll make sure to document this when we submit the next version 
of the patch.
> and then
>
> # mount -t cgroup -o name=th none /home/glyn/h2
>
> > 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...
> Yeah, this can only confuse people.
>
> I don't think we need extra explanation, because we all know the same
> filesystem can have more than one mount point, and cgroupfs is no
> different.
Thanks.
> > ---
> >   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/