Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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




  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