From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: kernel test robot <oliver.sang@intel.com>,
"Harry Yoo (Oracle)" <harry@kernel.org>
Cc: oe-lkp@lists.linux.dev, lkp@intel.com, Hao Li <hao.li@linux.dev>,
linux-mm@kvack.org
Subject: Re: [linux-next:master] [mm, slab] 298cdbf5f7: will-it-scale.per_process_ops 6.3% regression
Date: Thu, 14 May 2026 18:00:06 +0200 [thread overview]
Message-ID: <eda98e7b-67fd-4a36-9d39-3de26827599b@kernel.org> (raw)
In-Reply-To: <90bf195e-45fb-423c-b686-49be9cadbd11@kernel.org>
On 5/14/26 16:45, Vlastimil Babka (SUSE) wrote:
> On 5/11/26 16:45, kernel test robot wrote:
>>
>>
>> Hello,
>>
>> kernel test robot noticed a 6.3% regression of will-it-scale.per_process_ops on:
>
> Yay for an optimization that was supposed to have no tradeoffs :)
Does this help? I don't expect much, but perhaps...
- list_empty(&pc.slabs) is no longer unlikely when it can likely have a slab
where we returned part of the freelist
- let's ignore s->min_partial when returning slabs, we just pulled them from
the list, it's unlikely there are too many free slabs, and unlikely we have
free slabs to return. Maybe it will reduce the page alloc/frees and the code
is simpler
From 761946747d53b880855ac1e795ae0627be416c3e Mon Sep 17 00:00:00 2001
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Date: Thu, 14 May 2026 17:55:31 +0200
Subject: [PATCH] mm, slab: simplify __refill_objects_node
---
mm/slub.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 5d867349912b..0cc6c88f11e3 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -7187,26 +7187,16 @@ __refill_objects_node(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int mi
break;
}
- if (unlikely(!list_empty(&pc.slabs))) {
+ if (!list_empty(&pc.slabs)) {
spin_lock_irqsave(&n->list_lock, flags);
list_for_each_entry_safe(slab, slab2, &pc.slabs, slab_list) {
- if (unlikely(!slab->inuse && n->nr_partial >= s->min_partial))
- continue;
-
list_del(&slab->slab_list);
add_partial(n, slab, ADD_TO_HEAD);
}
spin_unlock_irqrestore(&n->list_lock, flags);
-
- /* any slabs left are completely free and for discard */
- list_for_each_entry_safe(slab, slab2, &pc.slabs, slab_list) {
-
- list_del(&slab->slab_list);
- discard_slab(s, slab);
- }
}
return refilled;
--
2.54.0
next prev parent reply other threads:[~2026-05-14 16:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 14:45 [linux-next:master] [mm, slab] 298cdbf5f7: will-it-scale.per_process_ops 6.3% regression kernel test robot
2026-05-14 14:45 ` Vlastimil Babka (SUSE)
2026-05-14 16:00 ` Vlastimil Babka (SUSE) [this message]
2026-05-14 16:02 ` 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=eda98e7b-67fd-4a36-9d39-3de26827599b@kernel.org \
--to=vbabka@kernel.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox