Re: [RFC] cgroup TODOs

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

On 09/17/2012 09:21 PM, Tejun Heo wrote:
> Hello, Glauber.
> 
> On Mon, Sep 17, 2012 at 12:50:47PM +0400, Glauber Costa wrote:
>>> Can you be a bit more specific?
>>
>> What I mean is that if some operation needs to operate locked, they will
>> have to lock. Whether or not the locking is called from cgroup core or
>> not. If the lock is not available outside, people will end up calling a
>> core function that locks.
> 
> I was asking whether you have certain specific operations on mind.
> 
>>>> And the problem is that people need to lock. cgroup_lock is needed
>>>> because the data you are accessing is protected by it. The way I see it,
>>>> it is incredible how we were able to revive the BKL in the form of
>>>> cgroup_lock after we finally manage to successfully get rid of it!
>>>
>>> I wouldn't go as far as comparing it to BKL.
>>
>> Of course not, since it is not system-wide. But I think the comparison
>> still holds in spirit...
> 
> Subsystem-wide locks covering non-hot paths aren't evil things.  We
> have a lot of them and they work fine.  BKL was a completely different
> beast initially with implicit locking on kernel entry and unlocking on
> sleeping and then got morphed into some chimera inbetween afterwards.
> 
> Simple locking is a good thing.  If finer-grained locking is
> necessary, we sure do that but please stop throwing over-generalized
> half-arguments at it.  It doesn't help anything.
> 
>> you seem to hear "comount", and think of unified vision, and that is the
>> reason for this discussion to still be going on. Mounting is all about
>> the root. And if you comount, hierarchies have the same root.
>>
>> In your example, the different controllers are comounted. They have not
>> the same view, but the possible views are restricted to be a subset of
>> the underlying tree - because they are mounted in the same place, forced
>> or not.
> 
> Heh, I can't really tell whether you understand it or not.  Here and
> in the previous thread too.  You seem to understand that there are
> different views upto this point.
> 
>> In a situation like this, it makes all the sense in the world to use the
>> css_id as a primary identifier, because it will be guaranteed to be the
> 
> And then you say something like this (or that this would remove
> walking different hierarchies in the previous thread - yes, to a
> certain point but not completely).  css_id is a per-css attribute.
> How can that be the "primariy" identifier when there can be multiple
> views?  For each userland-visible cgroup, there must be a css_set
> which points to the css's belonging to it, which may not be at the
> same level - multiple nodes in the userland visible tree may point to
> the same css.
> 
> If you mean that css_id would be the primary identifier for that
> specific controller's css, why even say that?  That's true now and
> won't ever change.
> 
>> same. What makes the tree overly flexible, is that you can have multiple
>> roots, starting in multiple places, with arbitrary topologies downwards.
> 
> And now you seem to be on the same page again.  But then again, you're
> asserting that incorporating forced co-mounts *now* is a gradual step
> towards the goal, which is utterly bonkers.  I don't know.  I just
> can't understand what you're thinking at all.
> 
> Thanks.
> 
I will just stop, because i am not trying to convince you to do anything
different than you are proposing now. I am just trying to convince you
what I have been saying has the exact same effects of this.

So let us focus our energies in the actual work