Re: [PATCH 1/3] mm, slub: not retrieve cpu_slub again in new_slab_objects()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Christopher

I got one confusion on understanding one case in __slab_free().

The case is     : (new.frozen && !was_frozen)
My confusion is : Is it possible for the page to be on the full list?

This case (new.frozen && !was_frozen) happens when (!prior && !was_frozen).

  * !prior means this page is full
  * !was_frozen means this page is not in cpu_slab->page/partial

There are two cases to lead to (!prior && !was_frozen):

  * in get_freelist(), when page is full
  * in deactivate_slab(), when page is full

The first case will have a page in no list.
The second case will have a page in no list, or the page is put into
full list if SLUB_DEBUG is configured.

Do I miss something?

On Thu, Oct 25, 2018 at 01:46:49PM +0000, Christopher Lameter wrote:
>On Thu, 25 Oct 2018, Wei Yang wrote:
>
>> In current code, the following context always meets:
>>
>>   local_irq_save/disable()
>>     ___slab_alloc()
>>       new_slab_objects()
>>   local_irq_restore/enable()
>>
>> This context ensures cpu will continue running until it finish this job
>> before yield its control, which means the cpu_slab retrieved in
>> new_slab_objects() is the same as passed in.
>
>Interrupts can be switched on in new_slab() since it goes to the page
>allocator. See allocate_slab().
>
>This means that the percpu slab may change.

-- 
Wei Yang
Help you, Help me




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux