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