Re: [PATCH] control groups: documentation improvements

[Glyn Normington <gnormington@gopivotal.com>]

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. ;-)
>>
>>
>> .
>>