On Tue, Sep 11, 2012 at 11:22:10AM -0700, Tejun Heo wrote: [..] > > The point I am trying to make is that deep hierarchies (5-6 levels) are > > /going to be a reality and if accounting overhead is not manageable then > > enabling hierarchy by default might not be a practical solution even > > if you implement hierarchy support (like memory cgroup), and in that > > case retaining .use_hierarchy will make sense. > > That doesn't make any sense to me. If you don't want feature and > overhead of hierarchy, you just need to not create a hierarchy. If > hierarchical behavior isn't needed, why create hierarchy at all?
I think ease of use and creation in user space. Different subsystems (systemd/libvirt etc), don't have to fight each other by keeping cgroups at same level. So systemd can control top 2 level of hiearchies and then libvirt can manage another 2-3 levels. systemd is not enforcing any upper limits. And if libvirt wants to enforce upper memory limits per VM, they can still easily do that using flat controller (and without incurring the overhead of hierarchical accounting). Having said that, I think somebody had mentioned that it would be nice to have hierarchical features to that a limit can be imposed on a group of virtual machines without having all virtual machines in same cgroup. So yes agreed that creating hierarchy and still not expecting hierarchical behavior does not make much sense. I think it kind of worked for limited requirements (per cgroup upper limit). I think once you make hierarchy default and if accounting overhead shows up, then there will be noises about introducing regression. Anyway, thanks for the explanation. This roadmap of converting everything to hierarchical by default sounds sane. (Hoepefully we will be able to manage the overhead problem). Thanks Vivek -- 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/
