Re: [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with brokenhierarchy support and whine if cgroups are nested for them

[Vivek Goyal]

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