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

[Glauber Costa <glommer@parallels.com>]

>>    And because there is nothing to gain, it is in addition really
>>    trivial to fix the insane setups by simply undoing the nesting,
>>    there is no downside for them.
>
> I have to disagree with that.  Deployment sometimes can be very
> painful.  In some cases, even flipping single parameter in sysfs
> depending on kernel version takes considerable effort.  The behavior
> has been the contract that we offered userland for quite some time
> now.  We shouldn't be changing that underneath them without any clear
> way for them to notice it.

Yes, and that's why once you deploy, you keep your updates to a minimum. 
Because hell, even *perfectly legitimate bug fixes* can change your 
behavior in a way you don't want. And you don't expect people to refrain 
from fixing bugs because of that.

>
>> The only point where I agree with you is that it may indeed be
>> non-obvious to detect in case you were relying on the filesystem
>> hierarchy not being reflected in the controller hierarchy.  But even
>> that depends on the usecase, whether it's a subtle performance
>> regression or a total failure to execute a previously supported
>> workload, which would be pretty damn obvious.
>
> And imagine that happening in serveral thousand machine cluster with
> fairly complicated cgroup setup and kernel update rolling out for
> subset of machine types.  I would be screaming bloody murder.


That is precisely why people in serious environments tend to run 
-stable, distro LTSes, or anything like that. Because they don't want 
any change, however minor, to potentially affect their stamped behavior. 
I am not proposing this patch to -stable, btw...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>