From: Hao Li <hao.li@linux.dev>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
Harry Yoo <harry@kernel.org>
Cc: akpm@linux-foundation.org, cl@gentwo.org, rientjes@google.com,
roman.gushchin@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slub: batch-detach node partial slabs
Date: Wed, 27 May 2026 14:08:34 +0800 [thread overview]
Message-ID: <ahaGwwbPyfFu-CM_@fedora> (raw)
In-Reply-To: <3bfbb8cd-6291-43e8-9f0e-b8b0b3c568d1@kernel.org>
On Tue, May 26, 2026 at 03:41:55PM +0200, Vlastimil Babka (SUSE) wrote:
> On 5/26/26 9:37 AM, Harry Yoo wrote:
> >
> >
> > On 5/25/26 12:22 PM, Hao Li wrote:
> >> get_partial_node_bulk() used to move each selected slab from the node
> >> 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, so this repeatedly manipulates list pointers while holding
> >> n->list_lock, which causes unnecessary churn.
> >>
> >> Instead, track contiguous runs of matching slabs and move each run with
> >> list_bulk_move_tail() in one operation.
> >
> > TIL list_bulk_move_tail() :D
> >
> >> This reduces list pointer churn> inside the lock critical section.
>
> Nice!
>
> > Similar to this, can we return all slabs in pc->slabs at once when
> > returning those slabs to the list? ... I see Vlastimil removed 'nr of
> > empty slabs' check in the other series already.
> >
> > Now that it inserts slabs to the tail with Vlastimil's patchset, let's
> > do a list_splice_tail() instead?
>
> Why not, although it should be rare to return more than one slab in that
> path.
Yeah, it's definitely still worth doing.
> So in case this change gets tricky for some reason, we can leave it.
sure, I will try and test.
>
> BTW, if you also get the same idea as I had and try to replace the
> current "remove from pc.slabs initially, reinsert to pc.slabs if it was
> a partial refill" with a "keep in pc.slabs and only remove if the refill
> was full" to reduce pointer churn, don't try that, it crashes rather
> quickly :D
Ah, fair enough. But honestly, it did seem like a good idea initially.
>
> >> The mmap2 testcase shows a 5% improvement after applying this patch.
> >>
> >> Signed-off-by: Hao Li <hao.li@linux.dev>
> >> ---
> >> mm/slub.c | 22 ++++++++++++++++++----
> >> 1 file changed, 18 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index 04692a6f9128..180973a4a3d2 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -3775,15 +3783,21 @@ 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;
> >
> >> + slab_clear_node_partial(slab);
> >> + n->nr_partial--;
> >
> > Perhaps factor out those two statements into to a common function and
> > call it in get_partial_node_bulk() and remove_partial()?
> >> 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;
> >> }
> >
>
--
Thanks,
Hao
prev parent reply other threads:[~2026-05-27 6:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 3:22 [PATCH] mm/slub: batch-detach node partial slabs Hao Li
2026-05-26 7:37 ` Harry Yoo
2026-05-26 9:08 ` Hao Li
2026-05-26 13:41 ` Vlastimil Babka (SUSE)
2026-05-27 6:08 ` Hao Li [this message]
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=ahaGwwbPyfFu-CM_@fedora \
--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.