Re: [RFC] SL[AUO]B common code 5/9] slabs: Common definition for boot state of the slab allocators

Glauber Costa
2012-05-17T14:10:31Z

On 05/17/2012 06:07 PM, Christoph Lameter wrote:
> On Thu, 17 May 2012, Glauber Costa wrote:
>
>> On 05/16/2012 06:31 PM, Christoph Lameter wrote:
>>>> There are a couple of places where that test seems to be okay (I remember
>>>> 1 in
>>>>> the slub), but at least for the "FULL" test here, we should be
>>>> testing>=
>>>>> FULL.
>>>>>
>>>>> Also, I don't like the name FULL too much, since I do intend to add a
>>>> new one
>>>>> soon (MEMCG, as you can see in my series)
>>> Ok. Why would memcg need an additional state?
>>
>> Please refer to my patchset for the full story.
>> I add state both to the slab and to the slub for that.
>>
>> But in summary, it is not unlike the "SYSFS" state: we depend on something
>> else outside of the slab domain to be ready before we can proceed.
>>
>> Specifically, we need to register each cache with an index. And for that, we
>> use idr/ida. When it is ready, we run code to register indexes for all caches
>> that are already available. After that, we just grab an index right away -
>> much like sysfs state for aliases.
>
> Why can this processing not be done when sysfs has just been initialized?

If we can be 100 % sure that idr/ida is always initialized before sysfs,
than yes, we can.

>>>>> Since we are using slab-specific states like PARTIAL_L3 here, maybe we
>>>> can use
>>>>> slub's like SYSFS here with no problem.
>>> Sure. I thought there would only be special states before UP.
>>>
>>>>> If we stick to>= and<= whenever needed, that should reflect a lot
>>>> better
>>>>> what the algorithm is really doing
>>> How so?
>>
>> In the sense that we very rarely want to do some action *at a specific
>> moment*. Most of the time we want to separate the world into before and after
>> a state. We test == instead of<= and>=, and it happens to work because of
>> the specific order of things, which are subject to change in a rework or
>> another...
>
> The reason to use == is because we want things to happen only at a
> particular stage of things. The == SYSFS means we will only do an action
> if the slab system is fully functional. Such things will have to be
> reevaluated if the number of states change.

Yes, but you are actually arguing in my favor. "fully functional" means
>= SYSFS, not == SYSFS.

If for whatever reordering people may decide doing another state is
added, or this function is called later, that will fail