Re: [PATCH v2] slub: keep empty main sheaf as spare in __pcs_replace_empty_main()
From: Zhao Liu
Date: Fri Jan 16 2026 - 03:42:04 EST
> > The following is the perf data comparing 2 tests w/o fix & with this fix:
> >
> > # Baseline Delta Abs Shared Object Symbol
> > # ........ ......... ....................... ....................................
> > #
> > 61.76% +4.78% [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
> > 0.93% -0.32% [kernel.vmlinux] [k] __slab_free
> > 0.39% -0.31% [kernel.vmlinux] [k] barn_get_empty_sheaf
> > 1.35% -0.30% [kernel.vmlinux] [k] mas_leaf_max_gap
> > 3.22% -0.30% [kernel.vmlinux] [k] __kmem_cache_alloc_bulk
> > 1.73% -0.20% [kernel.vmlinux] [k] __cond_resched
> > 0.52% -0.19% [kernel.vmlinux] [k] _raw_spin_lock_irqsave
> > 0.92% +0.18% [kernel.vmlinux] [k] _raw_spin_lock
> > 1.91% -0.15% [kernel.vmlinux] [k] zap_pmd_range.isra.0
> > 1.37% -0.13% [kernel.vmlinux] [k] mas_wr_node_store
> > 1.29% -0.12% [kernel.vmlinux] [k] free_pud_range
> > 0.92% -0.11% [kernel.vmlinux] [k] __mmap_region
> > 0.12% -0.11% [kernel.vmlinux] [k] barn_put_empty_sheaf
> > 0.20% -0.09% [kernel.vmlinux] [k] barn_replace_empty_sheaf
> > 0.31% +0.09% [kernel.vmlinux] [k] get_partial_node
> > 0.29% -0.07% [kernel.vmlinux] [k] __rcu_free_sheaf_prepare
> > 0.12% -0.07% [kernel.vmlinux] [k] intel_idle_xstate
> > 0.21% -0.07% [kernel.vmlinux] [k] __kfree_rcu_sheaf
> > 0.26% -0.07% [kernel.vmlinux] [k] down_write
> > 0.53% -0.06% libc.so.6 [.] __mmap
> > 0.66% -0.06% [kernel.vmlinux] [k] mas_walk
> > 0.48% -0.06% [kernel.vmlinux] [k] mas_prev_slot
> > 0.45% -0.06% [kernel.vmlinux] [k] mas_find
> > 0.38% -0.06% [kernel.vmlinux] [k] mas_wr_store_type
> > 0.23% -0.06% [kernel.vmlinux] [k] do_vmi_align_munmap
> > 0.21% -0.05% [kernel.vmlinux] [k] perf_event_mmap_event
> > 0.32% -0.05% [kernel.vmlinux] [k] entry_SYSRETQ_unsafe_stack
> > 0.19% -0.05% [kernel.vmlinux] [k] downgrade_write
> > 0.59% -0.05% [kernel.vmlinux] [k] mas_next_slot
> > 0.31% -0.05% [kernel.vmlinux] [k] __mmap_new_vma
> > 0.44% -0.05% [kernel.vmlinux] [k] kmem_cache_alloc_noprof
> > 0.28% -0.05% [kernel.vmlinux] [k] __vma_enter_locked
> > 0.41% -0.05% [kernel.vmlinux] [k] memcpy
> > 0.48% -0.04% [kernel.vmlinux] [k] mas_store_gfp
> > 0.14% +0.04% [kernel.vmlinux] [k] __put_partials
> > 0.19% -0.04% [kernel.vmlinux] [k] mas_empty_area_rev
> > 0.30% -0.04% [kernel.vmlinux] [k] do_syscall_64
> > 0.25% -0.04% [kernel.vmlinux] [k] mas_preallocate
> > 0.15% -0.04% [kernel.vmlinux] [k] rcu_free_sheaf
> > 0.22% -0.04% [kernel.vmlinux] [k] entry_SYSCALL_64
> > 0.49% -0.04% libc.so.6 [.] __munmap
> > 0.91% -0.04% [kernel.vmlinux] [k] rcu_all_qs
> > 0.21% -0.04% [kernel.vmlinux] [k] __vm_munmap
> > 0.24% -0.04% [kernel.vmlinux] [k] mas_store_prealloc
> > 0.19% -0.04% [kernel.vmlinux] [k] __kmalloc_cache_noprof
> > 0.34% -0.04% [kernel.vmlinux] [k] build_detached_freelist
> > 0.19% -0.03% [kernel.vmlinux] [k] vms_complete_munmap_vmas
> > 0.36% -0.03% [kernel.vmlinux] [k] mas_rev_awalk
> > 0.05% -0.03% [kernel.vmlinux] [k] shuffle_freelist
> > 0.19% -0.03% [kernel.vmlinux] [k] down_write_killable
> > 0.19% -0.03% [kernel.vmlinux] [k] kmem_cache_free
> > 0.27% -0.03% [kernel.vmlinux] [k] up_write
> > 0.13% -0.03% [kernel.vmlinux] [k] vm_area_alloc
> > 0.18% -0.03% [kernel.vmlinux] [k] arch_get_unmapped_area_topdown
> > 0.08% -0.03% [kernel.vmlinux] [k] userfaultfd_unmap_complete
> > 0.10% -0.03% [kernel.vmlinux] [k] tlb_gather_mmu
> > 0.30% -0.02% [kernel.vmlinux] [k] ___slab_alloc
> >
> > I think the insteresting item is "get_partial_node". It seems this fix
> > makes "get_partial_node" slightly more frequent. HMM, however, I still
> > can't figure out why this is happening. Do you have any thoughts on it?
>
> I'm not sure if it's statistically significant or just noise, +0.09% could
> be noise?
small number does't always mean it's noise. When perf samples get_partial_node
on the spin lock call chain, its subroutines (spin lock) are hotter, so
the proportion of subroutine execution is higher. If the function -
get_partial_node itself (excluding subroutines) executes very quickly,
the proportion is lower.
I also expend the perf data with call chain:
* w/o fix:
We can calculate the proportion of spin locks introduced by get_partial_node
is: 31.05% / 49.91% = 62.21%
49.91% mmap2_processes [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
|
--49.91%--native_queued_spin_lock_slowpath
|
--49.91%--_raw_spin_lock_irqsave
|
|--31.05%--get_partial_node
| |
| |--23.66%--get_any_partial
| | ___slab_alloc
| |
| --7.40%--___slab_alloc
| __kmem_cache_alloc_bulk
|
|--10.84%--barn_get_empty_sheaf
| |
| |--6.18%--__kfree_rcu_sheaf
| | kvfree_call_rcu
| |
| --4.66%--__pcs_replace_empty_main
| kmem_cache_alloc_noprof
|
|--5.10%--barn_put_empty_sheaf
| |
| --5.09%--__pcs_replace_empty_main
| kmem_cache_alloc_noprof
|
|--2.01%--barn_replace_empty_sheaf
| __pcs_replace_empty_main
| kmem_cache_alloc_noprof
|
--0.78%--__put_partials
|
--0.78%--__kmem_cache_free_bulk.part.0
rcu_free_sheaf
* with fix:
Similarly, the proportion of spin locks introduced by get_partial_node
is: 39.91% / 42.82% = 93.20%
42.82% mmap2_processes [kernel.vmlinux] [k] native_queued_spin_lock_slowpath
|
---native_queued_spin_lock_slowpath
|
--42.82%--_raw_spin_lock_irqsave
|
|--39.91%--get_partial_node
| |
| |--28.25%--get_any_partial
| | ___slab_alloc
| |
| --11.66%--___slab_alloc
| __kmem_cache_alloc_bulk
|
|--1.09%--barn_get_empty_sheaf
| |
| --0.90%--__kfree_rcu_sheaf
| kvfree_call_rcu
|
|--0.96%--barn_replace_empty_sheaf
| __pcs_replace_empty_main
| kmem_cache_alloc_noprof
|
--0.77%--__put_partials
__kmem_cache_free_bulk.part.0
rcu_free_sheaf
So, 62.21% -> 93.20% could reflect that get_partial_node contribute more
overhead at this point.
> > So, I'd like to know if you think dynamically or adaptively adjusting
> > capacity is a worthwhile idea.
>
> In the followup series, there will be automatically determined capacity to
> roughly match the current capacity of cpu partial slabs:
>
> https://lore.kernel.org/all/20260112-sheaves-for-all-v2-4-98225cfb50cf@xxxxxxx/
>
> We can use that as starting point for further tuning. But I suspect making
> it adjust dynamically would be complicated.
Thanks, will continue to evaluate this series.
Regards,
Zhao