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?
