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

Glauber Costa glommer at parallels.com
Fri Sep 14 08:19:06 UTC 2012


On 09/13/2012 09:39 PM, Michal Hocko wrote:
> On Thu 13-09-12 10:18:32, Tejun Heo wrote:
>> Hello, Michal.
>>
>> On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
>>> I would like to see use_hierarchy go away. The only concern I have is 
>>> to warn only if somebody is doing something wrong (aka flat
>>> hierarchies). Or better put it this way. Do not warn in cases which do
>>> not change if use_hierarchy is gone or default changes to 1.
>>> An example:
>>> root (use_hierarchy=0)
>>>  | \
>>>  |  A (use_hierarchy=0)
>>>  |
>>>  B (use_hierarachy=1)
>>>  |\
>>>  C D
>>>
>>> is a perfectly sane configuration and I do not see any reason to fill
>>> logs with some scary warnings when A is created. There will be no
>>> semantical change in this setup When use_hierchy is gone.
>>>
>>> So the only thing I am proposing here is to warn only if something
>>> should be fixed in the configuration in order to be prepared for fully
>>> hierarchical (and that is a second level of children from root with
>>> use_hierachy==0).
>>>
>>> Does it make more sense now?
>>
>> Ah, okay, so what you're saying is that we shouldn't warn if 0
>> .use_hierarchys don't make any behavior difference from when they're
>> all 1, right?  
> 
> Exactly. 1st level of children under the root is exactly this kind of
> setup.
> 
>> If so, I have no objection.  Will incorporate your updated version.
> 
> Thanks!
> 
I want oppose it as well, but I believe part of this exercise is to make
the need to have hierarchy widespread. Warning on the case
1st-level-only case helps with that, even if we make more noise than we
should.

The reason I supported Tejun's proposal originally, is that I think that
if we make the wrong amount of noise, being wrong by a surplus is better
than being wrong by a deficit, in this case.



More information about the Containers mailing list