From: Hao Li <hao.li@linux.dev>
To: vbabka@kernel.org, harry@kernel.org, akpm@linux-foundation.org
Cc: cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hao Li <hao.li@linux.dev>
Subject: [PATCH v3 2/2] mm/slub: detach and reattach partial slabs in batch
Date: Fri, 29 May 2026 11:50:52 +0800 [thread overview]
Message-ID: <20260529035120.81304-3-hao.li@linux.dev> (raw)
In-Reply-To: <20260529035120.81304-1-hao.li@linux.dev>
get_partial_node_bulk() moves each selected slab from the node's
partial list to the local pc->slabs list using a remove_partial() and
list_add() pair. In practice, the loop often detaches several adjacent
slabs. Doing this individually repeatedly manipulates list pointers
while holding n->list_lock, which causes unnecessary churn.
To demonstrate this, the counts below show how often single vs. multiple
consecutive slabs are retrieved during a will-it-scale mmap stress test:
consecutive_slabs_count frequency
= 1 277345324
= 2 335238023
= 3 175717884
>= 4 88862337
The data confirms that retrieving multiple contiguous slabs is highly
frequent.
To optimize this, track contiguous runs of matching slabs and move each
run in a single operation using list_bulk_move_tail(). This reduces list
pointer churn inside the lock critical section.
Apply the same optimization to __refill_objects_node() when reattaching
leftover partial slabs back to the node's partial list.
The will-it-scale mmap benchmark shows a 2% ~ 5% performance improvement
after applying this patch.
Signed-off-by: Hao Li <hao.li@linux.dev>
---
mm/slub.c | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 45aa0a834f97..4fdf5c36a69b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3751,6 +3751,7 @@ static bool get_partial_node_bulk(struct kmem_cache *s,
bool allow_spin)
{
struct slab *slab, *slab2;
+ struct slab *first = NULL, *last = NULL;
unsigned int total_free = 0;
unsigned long flags;
@@ -3769,8 +3770,15 @@ static bool get_partial_node_bulk(struct kmem_cache *s,
struct freelist_counters flc;
unsigned int slab_free;
- if (!pfmemalloc_match(slab, pc->flags))
+ if (!pfmemalloc_match(slab, pc->flags)) {
+ if (first) {
+ list_bulk_move_tail(&pc->slabs,
+ &first->slab_list,
+ &last->slab_list);
+ first = NULL;
+ }
continue;
+ }
/*
* determine the number of free objects in the slab racily
@@ -3787,15 +3795,20 @@ static bool get_partial_node_bulk(struct kmem_cache *s,
&& total_free + slab_free > pc->max_objects)
break;
- remove_partial(n, slab);
-
- list_add(&slab->slab_list, &pc->slabs);
+ if (!first)
+ first = slab;
+ last = slab;
+ clear_node_partial_state(n, slab);
total_free += slab_free;
if (total_free >= pc->max_objects)
break;
}
+ if (first)
+ list_bulk_move_tail(&pc->slabs, &first->slab_list,
+ &last->slab_list);
+
spin_unlock_irqrestore(&n->list_lock, flags);
return total_free > 0;
}
@@ -7206,11 +7219,10 @@ __refill_objects_node(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int mi
if (!list_empty(&pc.slabs)) {
spin_lock_irqsave(&n->list_lock, flags);
- list_for_each_entry_safe(slab, slab2, &pc.slabs, slab_list) {
+ list_for_each_entry(slab, &pc.slabs, slab_list)
+ set_node_partial_state(n, slab);
- list_del(&slab->slab_list);
- add_partial(n, slab, ADD_TO_TAIL);
- }
+ list_splice_tail(&pc.slabs, &n->partial);
spin_unlock_irqrestore(&n->list_lock, flags);
}
--
2.54.0
next prev parent reply other threads:[~2026-05-29 3:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 3:50 [PATCH v3 0/2] mm/slub: batch partial slab list operations Hao Li
2026-05-29 3:50 ` [PATCH v3 1/2] mm/slub: introduce helpers for node partial slab state Hao Li
2026-06-01 3:38 ` Harry Yoo
2026-06-01 5:26 ` Hao Li
2026-06-01 6:17 ` Harry Yoo
2026-05-29 3:50 ` Hao Li [this message]
2026-06-01 3:51 ` [PATCH v3 2/2] mm/slub: detach and reattach partial slabs in batch Harry Yoo
2026-05-29 8:01 ` [PATCH v3 0/2] mm/slub: batch partial slab list operations Vlastimil Babka (SUSE)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260529035120.81304-3-hao.li@linux.dev \
--to=hao.li@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=harry@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.