Re: [vbabka:b4/sheaves-for-all-rebased] [slab] aa8fdb9e25: will-it-scale.per_process_ops 46.5% regression
Vlastimil Babka <[email protected]>
| Newsgroups | dev.linux.lists.oe-lkp,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 1/13/26 14:57, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a 46.5% regression of will-it-scale.per_process_ops on:
>
>
> commit: aa8fdb9e2516055552de11cabaacde4d77ad7d72 ("slab: refill sheaves from all nodes")
> https://git.kernel.org/cgit/linux/kernel/git/vbabka/linux.git b4/sheaves-for-all-rebased
>
> testcase: will-it-scale
> config: x86_64-rhel-9.4
> compiler: gcc-14
> test machine: 192 threads 2 sockets Intel(R) Xeon(R) 6740E CPU @ 2.4GHz (Sierra Forest) with 256G memory
> parameters:
>
> nr_task: 100%
> mode: process
> test: mmap2
> cpufreq_governor: performance
>
>
> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+----------------------------------------------------------------------------------------------------+
> | testcase: change | stress-ng: stress-ng.pkey.ops_per_sec 28.4% regression |
> | test machine | 192 threads 2 sockets Intel(R) Xeon(R) 6740E CPU @ 2.4GHz (Sierra Forest) with 256G memory |
> | test parameters | cpufreq_governor=performance |
> | | nr_threads=100% |
> | | test=pkey |
> | | testtime=60s |
> +------------------+----------------------------------------------------------------------------------------------------+
> | testcase: change | will-it-scale: will-it-scale.per_process_ops 32.8% regression |
> | test machine | 224 threads 4 sockets Intel(R) Xeon(R) Platinum 8380H CPU @ 2.90GHz (Cooper Lake) with 192G memory |
> | test parameters | cpufreq_governor=performance |
> | | mode=process |
> | | nr_task=100% |
> | | test=brk2 |
> +------------------+----------------------------------------------------------------------------------------------------+
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-lkp/[email protected]
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260113/[email protected]
>
> =========================================================================================
> compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
> gcc-14/performance/x86_64-rhel-9.4/process/100%/debian-13-x86_64-20250902.cgz/lkp-srf-2sp2/mmap2/will-it-scale
>
> commit:
> 6a67958ab0 ("slab: remove unused PREEMPT_RT specific macros")
> aa8fdb9e25 ("slab: refill sheaves from all nodes")
Hi,
as discussed at [1] this particular commit restores a behavior analogical to
one that existed before sheaves, so while it may show a regression in
isolation, there should hopefully be also corresponding improvement in an
earlier commit, and those two more or less cancelled out.
What would be more useful is to know the whole series effect (excluding some
preparatory patches). Could you please compare that if anything stands out?
In next-20260127 that would be:
before: d86c9915f4b5 ("mm/slab: make caches with sheaves mergeable")
after: ca43eb67282a ("mm/slub: cleanup and repurpose some stat items")
Additionally, does the patch below improve anything? (on top of
ca43eb67282a). Thanks!
[1] https://lore.kernel.org/all/[email protected]/
----8<----
From 5ac96a0bde0c3ea5cecfb4e478e49c9f6deb9c19 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <[email protected]>
Date: Tue, 27 Jan 2026 22:40:26 +0100
Subject: [PATCH] slub: avoid list_lock contention from __refill_objects_any()
Signed-off-by: Vlastimil Babka <[email protected]>
---
mm/slub.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 7d7e1ae1922f..3458dfbab85d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3378,7 +3378,8 @@ static inline bool pfmemalloc_match(struct slab *slab, gfp_t gfpflags);
static bool get_partial_node_bulk(struct kmem_cache *s,
struct kmem_cache_node *n,
- struct partial_bulk_context *pc)
+ struct partial_bulk_context *pc,
+ bool allow_spin)
{
struct slab *slab, *slab2;
unsigned int total_free = 0;
@@ -3390,7 +3391,10 @@ static bool get_partial_node_bulk(struct kmem_cache *s,
INIT_LIST_HEAD(&pc->slabs);
- spin_lock_irqsave(&n->list_lock, flags);
+ if (allow_spin)
+ spin_lock_irqsave(&n->list_lock, flags);
+ else if (!spin_trylock_irqsave(&n->list_lock, flags))
+ return false;
list_for_each_entry_safe(slab, slab2, &n->partial, slab_list) {
struct freelist_counters flc;
@@ -6544,7 +6548,8 @@ EXPORT_SYMBOL(kmem_cache_free_bulk);
static unsigned int
__refill_objects_node(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int min,
- unsigned int max, struct kmem_cache_node *n)
+ unsigned int max, struct kmem_cache_node *n,
+ bool allow_spin)
{
struct partial_bulk_context pc;
struct slab *slab, *slab2;
@@ -6556,7 +6561,7 @@ __refill_objects_node(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int mi
pc.min_objects = min;
pc.max_objects = max;
- if (!get_partial_node_bulk(s, n, &pc))
+ if (!get_partial_node_bulk(s, n, &pc, allow_spin))
return 0;
list_for_each_entry_safe(slab, slab2, &pc.slabs, slab_list) {
@@ -6650,7 +6655,8 @@ __refill_objects_any(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int min
n->nr_partial <= s->min_partial)
continue;
- r = __refill_objects_node(s, p, gfp, min, max, n);
+ r = __refill_objects_node(s, p, gfp, min, max, n,
+ /* allow_spin = */ false);
refilled += r;
if (r >= min) {
@@ -6691,7 +6697,8 @@ refill_objects(struct kmem_cache *s, void **p, gfp_t gfp, unsigned int min,
return 0;
refilled = __refill_objects_node(s, p, gfp, min, max,
- get_node(s, local_node));
+ get_node(s, local_node),
+ /* allow_spin = */ true);
if (refilled >= min)
return refilled;
--
2.52.0