Re: [RFC] cgroup TODOs

[Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 09/14/2012 04:54 PM, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 01:15:02PM +0200, Peter Zijlstra wrote:
>> On Thu, 2012-09-13 at 13:58 -0700, Tejun Heo wrote:
>>>   The cpu ones handle nesting correctly - parent's accounting includes
>>>   children's, parent's configuration affects children's unless
>>>   explicitly overridden, and children's limits nest inside parent's. 
>>
>> The implementation has some issues with fixed point math limitations on
>> deep hierarchies/large cpu count, but yes.
>>
>> Doing soft-float/bignum just isn't going to be popular I guess ;-)
>>
>> People also don't seem to understand that each extra cgroup carries a
>> cost and that nested cgroups are more expensive still, even if the
>> intermediate levels are mostly empty (libvirt is a good example of how
>> not to do things).
>>
>> Anyway, I guess what I'm saying is that we need to work on the awareness
>> of cost associated with all this cgroup nonsense, people seem to think
>> its all good and free -- or not think at all, which, while depressing,
>> seem the more likely option.
> 
> In defense of what libvirt is doing, I'll point out that the kernel
> docs on cgroups make little to no mention of these performance / cost
> implications, and the examples of usage given arguably encourage use
> of deep hierarchies.
> 
> Given what we've now learnt about the kernel's lack of scalability
> wrt cgroup hierarchies, we'll be changing the way libvirt deals with
> cgroups, to flatten it out to only use 1 level by default. If the
> kernel docs had clearly expressed the limitations & made better
> recommendations on app usage we would never have picked the approach
> we originally chose.
> 
> Regards,
> Daniel
> 
I personally don't think this is such a crazy setup. It is perfectly
valid to say "all applications managed by libvirt as a whole cannot use
more than X". Now of course there are other ways to do it, and we really
need to make people more aware of the costs...