]> git.ipfire.org Git - thirdparty/linux.git/commit
mm/slab: allow sheaf refill if blocking is not allowed
authorVlastimil Babka (SUSE) <vbabka@kernel.org>
Mon, 2 Mar 2026 09:55:37 +0000 (10:55 +0100)
committerVlastimil Babka <vbabka@suse.cz>
Wed, 4 Mar 2026 10:03:54 +0000 (11:03 +0100)
commitfb1091febd668398aa84c161b8d9a1834321e021
tree04eb5b9671c11cc0bc20cfd4023878482cb83df0
parent48647d3f9a644d1e81af6558102d43cdb260597b
mm/slab: allow sheaf refill if blocking is not allowed

Ming Lei reported [1] a regression in the ublk null target benchmark due
to sheaves. The profile shows that the alloc_from_pcs() fastpath fails
and allocations fall back to ___slab_alloc(). It also shows the
allocations happen through mempool_alloc().

The strategy of mempool_alloc() is to call the underlying allocator
(here slab) without __GFP_DIRECT_RECLAIM first. This does not play well
with __pcs_replace_empty_main() checking for gfpflags_allow_blocking()
to decide if it should refill an empty sheaf or fallback to the
slowpath, so we end up falling back.

We could change the mempool strategy but there might be other paths
doing the same ting. So instead allow sheaf refill when blocking is not
allowed, changing the condition to gfpflags_allow_spinning(). The
original condition was unnecessarily restrictive.

Note this doesn't fully resolve the regression [1] as another component
of that are memoryless nodes, which is to be addressed separately.

Reported-by: Ming Lei <ming.lei@redhat.com>
Fixes: e47c897a2949 ("slab: add sheaves to most caches")
Link: https://lore.kernel.org/all/aZ0SbIqaIkwoW2mB@fedora/
Link: https://patch.msgid.link/20260302095536.34062-2-vbabka@kernel.org
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
mm/slub.c