]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
slub: avoid list_lock contention from __refill_objects_any()
authorVlastimil Babka <vbabka@suse.cz>
Thu, 29 Jan 2026 09:07:57 +0000 (10:07 +0100)
committerVlastimil Babka <vbabka@suse.cz>
Thu, 29 Jan 2026 09:10:20 +0000 (10:10 +0100)
commit40fd0acc45d06709b3b1eea77e50e13f4145dff0
tree97bf115aa4ed1c4be4c63bc7660a47a07906ee14
parent6f1912181ddfcf851a6670b4fa9c7dfdaf3ed46d
slub: avoid list_lock contention from __refill_objects_any()

Kernel test robot has reported a regression in the patch "slab: refill
sheaves from all nodes". When taken in isolation like this, there is
indeed a tradeoff - we prefer to use remote objects prior to allocating
new local slabs. It is replicating a behavior that existed before
sheaves for replenishing cpu (partial) slabs - now called
get_from_any_partial() to allocate a single object.

So the possibility of allocating remote objects is intended even if
remote accesses are then slower. But the profiles in the report also
suggested a contention on the list_lock spinlock. And that's something
we can try to avoid without much tradeoff - if someone else has the
spin_lock, it's more likely they are allocating from the node than
freeing to it, so we can skip it even if it means allocating a new local
slab - contributing to that lock's contention isn't worth it. It should
not result in partial slabs accumulating on the remote node.

Thus add an allow_spin parameter to __refill_objects_node() and
get_partial_node_bulk() to make the attempts from __refill_objects_any()
use only a trylock.

Reported-by: kernel test robot <oliver.sang@intel.com>
Link: https://lore.kernel.org/oe-lkp/202601132136.77efd6d7-lkp@intel.com
Link: https://patch.msgid.link/20260129-b4-refill_any_trylock-v1-1-de7420b25840@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
mm/slub.c