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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
