Hi Serge, >> I do have a very stupid question, however: LXC 0.9 used to set the >> cgroup to /lxc/$name. Now it's just /$name. Is that intentional? > > Hm, it was somewhat unconscious but I didn't really mean to do that. > Some cgroup subsystems do incur a performance penalty for every > extra directory we descend. But /lxc does make for a nice grouping. > > Do you (and others) have a preference? Should we stick with /lxc?
Well, thinking about it again, libvirt [1] seems to have adopted the layout /machine/$name.libvirt-$type in current versions, which doesn't seem unreasonable to me, so maybe we should go with /machine/$name.lxc in analogy to that scheme. Personally I don't use libvirt-lxc but I do use libvirt-qemu (although currently in an older version which still uses a legacy cgroup layout), so at least for me the /machine cgroup will probably exist anyway in the future. Also according to the same document [1], libvirt supports additional subdividing in the form of /machine/$foo.partition as a base dir, which doesn't seem to be a bad idea if you want to have some common resource limits on for example all machines of a given user. We could also support that in the form of an additional configuration option - i.e. use /machine/$name.lxc by default and allow for the usage of /machine/$foo.partition/$bar.lxc if a configuration option is specified. I can provide a patch for that if you wish. Just my 2ยข. [1] http://libvirt.org/cgroups.html -- Christian ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
