Re: [PATCH 2/8] cgroup: kill CSS_REMOVED

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

On 10/31/2012 09:25 PM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Oct 31, 2012 at 09:19:51PM +0400, Glauber Costa wrote:
>> I don't see post_create failing as a huge problem. The natural
>> synchronization point would be "right after post_create" - then you can
>> definitely tell that it is online. Although this can be viewed a bit as
>> "exposing internals", creating is different then destroying: When you
>> create, you may not have all data yet. When destroying, you do - and
>> want to get rid of it. So this kind of bootstrapping is pretty standard
>> and common.
> 
> More proper names for these callbacks would be,
> 
> 	->allocate()
> 	->online()
> 	->offline()
> 	->free()
> 
> And I may rename them.  I don't wanna make ->online() failable.  Why
> can't you just allocate everything from ->allocate() and use it from
> ->online()?
> 

Because I am allocating an array big enough to hold one entry per memcg.
The natural array index for this, is the css_id. Obviously, I don't want
this array to have 65k entries in size, so I resize it (doubling every
time) Because I don't know the css_id at this time, I have to do it later.

Another option for this - which I also considered - would be to use a
different index. We get more packing, since not all memcgs will be kmem
limited (and the index would contain only the kmem limited memcgs), and
we can allocate this index during ->create().

I initially picked the css_index because I though a specialized index
might be confusing. But if you feel strongly about all the allocations
happening inside ->create(), this would be a way to avoid it. Would you
prefer that?