Re: [PATCH 2/2] memcg: first step towards hierarchical controller

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

Hello, Michal.

On Wed, Jun 27, 2012 at 12:08:09AM +0200, Michal Hocko wrote:
> According to my experience, people usually create deeper subtrees
> just because they want to have memcg hierarchy together with other
> controller(s) and the other controller requires a different topology
> but then they do not care about memory.* attributes in parents.
> Those cases are not affected by this change because parents are
> unlimited by default.
> Deeper subtrees without hierarchy and independent limits are usually
> mis-configurations, and we would like to hear about those to help to fix
> them, or they are unfixable usecases which we want to know about as well
> (because then we have a blocker for the unified cgroup hierarchy, don't
> we).

Yeah, this is something I'm seriously considering doing from cgroup
core.  ie. generating a warning message if the user nests cgroups w/
controllers which don't support full hierarchy.

> >   Note that the default should still be flat hierarchy.
> > 
> > 2. Mark flat hierarchy deprecated and produce a warning message if
> >    memcg is mounted w/o hierarchy option for a year or two.
> 
> I would agree with you on this with many kernel configurables but
> this one doesn't fall in. There is a trivial fallback (set root to
> use_hierarchy=0) so the mount option seems like an overkill - yet
> another API to keep for some time...

Just disallow clearing .use_hierarchy if it was mounted with the
option?  We can later either make the file RO 1 for compatibility's
sake or remove it.

> So in short, I do think we should go the sanity path and end up
> with hierarchical trees and sooner we start the better.

I do agree with you in principle, but I still don't think we can
switch the default behavior underneath the users.

Thanks.

-- 
tejun