]> git.ipfire.org Git - thirdparty/linux.git/commit
slab: skip percpu sheaves for remote object freeing
authorVlastimil Babka <vbabka@suse.cz>
Wed, 3 Sep 2025 12:59:49 +0000 (14:59 +0200)
committerVlastimil Babka <vbabka@suse.cz>
Mon, 29 Sep 2025 07:21:16 +0000 (09:21 +0200)
commit989b09b73978a0b3dbee9ef343ab108742b1cc9f
tree9932a3e02c968d52dbf613b90809893f7555f31a
parent08294229210916c3b179186f3efa3b9c62a04678
slab: skip percpu sheaves for remote object freeing

Since we don't control the NUMA locality of objects in percpu sheaves,
allocations with node restrictions bypass them. Allocations without
restrictions may however still expect to get local objects with high
probability, and the introduction of sheaves can decrease it due to
freed object from a remote node ending up in percpu sheaves.

The fraction of such remote frees seems low (5% on an 8-node machine)
but it can be expected that some cache or workload specific corner cases
exist. We can either conclude that this is not a problem due to the low
fraction, or we can make remote frees bypass percpu sheaves and go
directly to their slabs. This will make the remote frees more expensive,
but if it's only a small fraction, most frees will still benefit from
the lower overhead of percpu sheaves.

This patch thus makes remote object freeing bypass percpu sheaves,
including bulk freeing, and kfree_rcu() via the rcu_free sheaf. However
it's not intended to be 100% guarantee that percpu sheaves will only
contain local objects. The refill from slabs does not provide that
guarantee in the first place, and there might be cpu migrations
happening when we need to unlock the local_lock. Avoiding all that could
be possible but complicated so we can leave it for later investigation
whether it would be worth it. It can be expected that the more selective
freeing will itself prevent accumulation of remote objects in percpu
sheaves so any such violations would have only short-term effects.

Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
mm/slab_common.c
mm/slub.c