Hi Serge, Thanks for your quick reply.
On Wed, May 2, 2012 at 4:14 PM, Serge Hallyn <serge.hal...@canonical.com> wrote: > The issue of what to do with control groups which do not support > hierarchies has been discussed on lkml recently. I thought (though > maybe I'm wrong) the decision was that such a subsystem would have > its cgroups available at leaf nodes, i.e. it's /xyz cgroup, if > composed with a devices cgroup which has /abc/xyz, would be > visible at /abc/xyz. IIRC one of the primary drivers of the need > for this was systemd support. > > Putting lxc cgroups under lxc/ is the right thing to do to cooperate > with other programs using cgroups, like libvirt. I don't think we > should punt on that. Rather, I personally think it's reasonable to say > that if you are using a cgroup which has max depth 1, you should mount > it separately. If you then want to use it with lxc, perhaps we should, > for now have a hack which specifis which cgroups do not support > hierarchies, and handle them specially? I guess you were talking about this thread https://lkml.org/lkml/2012/2/21/379 Thanks for the explanation. It's quite clear and could be useful for users asking them self the same question. -- William ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
