Re: [RFC PATCH v3 0/7] slub: Delay freezing of CPU partial slabs

[Christoph Lameter]

On Tue, 24 Oct 2023, chengming.zhou@xxxxxxxxx wrote:

> 2. Solution
> ===========
> We solve these problems by leaving slabs unfrozen when moving out of
> the node partial list and on CPU partial list, so "frozen" bit is 0.
>
> These partial slabs won't be manipulate concurrently by alloc path,
> the only racer is free path, which may manipulate its list when !inuse.
> So we need to introduce another synchronization way to avoid it, we
> reuse PG_workingset to keep track of whether the slab is on node partial
> list or not, only in that case we can manipulate the slab list.
>
> The slab will be delay frozen when it's picked to actively use by the
> CPU, it becomes full at the same time, in which case we still need to
> rely on "frozen" bit to avoid manipulating its list. So the slab will
> be frozen only when activate use and be unfrozen only when deactivate.

I think we have to clear our terminology a bit about what a "frozen" slab 
is.

Before this patch a frozen slab is not on the node partial list and 
therefore its state on the list does not have to be considered during 
freeing and other operations. The frozen slab could be actively allocated 
from.

> From the source:

*   Frozen slabs
 *
 *   If a slab is frozen then it is exempt from list management. It is not
 *   on any list except per cpu partial list. The processor that froze the
 *   slab is the one who can perform list operations on the slab. Other
 *   processors may put objects onto the freelist but the processor that
 *   froze the slab is the only one that can retrieve the objects from the
 *   slab's freelist.
 *


After this patch the PG_workingset indicates the state of being on 
the partial lists.

What does "frozen slab" then mean? The slab is being allocated from? Is 
that information useful or can we drop the frozen flag?

Update the definition?