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

[Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]

(2012/06/28 2:33), Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Jun 27, 2012 at 02:51:19PM +0200, Michal Hocko wrote:
>>> 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.
>>
>> This is a good idea.
>
> And I want each controller either to do proper hierarchy or not at all
> and disallow switching the behavior while mounted - at least disallow
> switching off hierarchy support dynamically.
>
>>> Just disallow clearing .use_hierarchy if it was mounted with the
>>> option?
>>
>> Dunno, mount option just doesn't feel right. We do not offer other
>> attributes to be set by them so it would be just confusing. Besides that
>> it would require an integration into existing tools like cgconfig which
>> is yet another pain just because of something that we never promissed to
>> keep a certain way. There are many people who don't work with mount&fs
>> cgroups directly but rather use libcgroup for that...
>
> If the default behavior has to be switched without extra input from
> userland, that should be noisy like hell and slow.  e.g. generate
> warning messages whenever userland does something which is to be
> deprecated - nesting when .use_hierarchy == 0, mixing .use_hierarchy
> == 0 / 1, and maybe later on, using .use_hierarchy == 0 at all.
>
> Hmm.... we need to switch other controllers over to hierarchical
> behavior too.  We may as well just do it from cgroup core.  Once we
> rule out all users of pseudo hierarchy - nesting with controllers
> which don't support hierarchy - switching on hierarchy support
> per-controller shouldn't cause much problem.
>
> How about the following then?
>
> * I'll add a way for controllers to tell cgroup core that full
>    hierarchy support is supported and a cgroup mount option to enable
>    hierarchy (cgroup core itself already uses a number of mount options
>    and libgroup or whatever should be able to deal with it).
>
>    cgroup will refuse to mount if the hierarchy option is specified
>    with a controller which doesn't support hierarchy and it will also
>    whine like crazy if the userland tries to nest without the mount
>    option specified.
>
>    Each controller must enforce hierarchy once so directed by cgroup
>    mount option.
>
> * While doing that, all applicable controllers will be updated to
>    support hierarchy.
>
> * After sufficient time has passed, nesting without the mount option
>    specified will be failed by cgroup core.
>
> As for memcg's .use_hierarchy, make it RO 1 if the cgroup indicates
> that hierarchy should be used.  Otherwise, I don't know but make sure
> it gets phased out out use somehow.
>


  The reason for use_hierarchy file was just _performance_, it _was_ terrible.
  Now it's not very good but not terrible.


You all may think this as crazy idea. How about versioning ?

Creating 'memory2'(memory cgroup v2) cgroup and mark 'memory' cgroup as deprecated,
and put it to feature-removal-list.

Of course, memory2 cgroup doesn't have use_hierarchy file and have kmem accounting.
We should disallow to use memory and memory2 at the same time.

Or, add version file to cgroup subsys ? select v2 as default...user can choose v1
with mount option if necessary, but it will not be maintained.
Is it too difficult or messy ?

To keep user experience, versioning is a way. And we can see how the changes
affects users.

Thanks,
-Kame