Re: [vbabka:b4/sheaves-for-all-rebased] [slab] aa8fdb9e25: will-it-scale.per_process_ops 46.5% regression

[Hao Li <hao.li@linux.dev>]

On Thu, Jan 29, 2026 at 09:47:02AM +0100, Vlastimil Babka wrote:
> On 1/29/26 08:05, Hao Li wrote:
> > On Wed, Jan 28, 2026 at 11:31:59AM +0100, Vlastimil Babka wrote:
> > Hi Vlastimil,
> > 
> > I conducted a few performance tests on my machine, and I'd like to share my
> > findings. While I'm not an expert in LKP-style performance testing, I hope these
> > results can still serve as a useful reference.
> > 
> > Machine Configuration:
> > - CPU: AMD, 2 sockets, 2 nodes per socket, total 192 CPUs
> > - SMT: Disabled
> > 
> > Kernel Version:
> > All tests were based on modifications to the 6.19-rc5 kernel.
> > 
> > Test Scenarios:
> > 0. 6.19-rc5 + Completely disabled the sheaf mechanism
> >     - This was done by set s->cpu_sheaves to NULL
> > 1. Unmodified 6.19-rc5
> > 2. 6.19-rc5 + sheaves-for-all patchset
> > 3. 6.19-rc5 + sheaves-for-all patchset + list_lock contention patch
> > 4. 6.19-rc5 + sheaves-for-all patchset + list_lock contention patch + increased
> >    the maple node sheaf capacity to 128.
> > 
> > Results:
> > 
> > - Performance change of 1 relative to 0:
> > 
> > ```
> > will-it-scale.64.processes  -25.3%
> > will-it-scale.128.processes -22.7%
> > will-it-scale.192.processes -24.4%
> > will-it-scale.per_process_ops -24.2%
> > ```
> > 
> > - Performance change of 2 relative to 1:
> > 
> > ```
> > will-it-scale.64.processes  -34.2%
> > will-it-scale.128.processes -32.9%
> > will-it-scale.192.processes -36.1%
> > will-it-scale.per_process_ops -34.4%
> > ```
> > 
> > - Performance change of 3 relative to 1:
> > 
> > ```
> > will-it-scale.64.processes  -24.8%
> > will-it-scale.128.processes -26.5%
> > will-it-scale.192.processes -29.24%
> > will-it-scale.per_process_ops -26.7%
> > ```
> 
> Oh cool, that shows the patch helps, so I'll proceed with it.
> IIUC with that the sheaves-for-all doesn't regress this benchmark anymore,
> the regression is from 6.18 initial sheaves introduction and related to
> maple tree sheaf size.

Yes, one of the factors contributing to the regression does seem to be the capacity
of the sheaf.  

And I feel that this regression may be difficult to completely resolve with this
lock optimization patch. I'll share my latest test results in response to the v4
patchset a bit later, where we can continue the discussion in more detail.

However, I believe this regression doesn't need to block the progress of the v4
patchset.

> 
> > - Performance change of 4 relative to 1:
> > 
> > ```
> > will-it-scale.64.processes  +18.0%
> > will-it-scale.128.processes +22.4%
> > will-it-scale.192.processes +26.9%
> > will-it-scale.per_process_ops +22.2%
> > ```
> > 
> > - Performance change of 4 relative to 0:
> > 
> > ```
> > will-it-scale.64.processes  -11.9%
> > will-it-scale.128.processes -5.3%
> > will-it-scale.192.processes -4.1%
> > will-it-scale.per_process_ops -7.3%
> > ```
> > 
> > From these results, enabling sheaves and increasing the sheaf capacity to 128
> > seems to bring the behavior closer to the old percpu partial list mechanism.
> 
> Yeah but it's a tradeoff so not something to do based on one microbenchmark.

Sure, exactly.

> 
> > However, I previously noticed differences[1] between my results on the AMD
> > platform and Zhao Liu's results on the Intel platform. This leads me to consider
> > the possibility of other influencing factors, such as CPU architecture
> > differences or platform-specific behaviors, that might be impacting the
> > performance results.
> 
> Yeah, these will-it-scale benchmarks are quite sensitive to that.
> 
> > I hope these results are helpful. I'd be happy to hear any feedback or
> 
> Very helpful, thanks!
> 
> > suggestions for further testing.
> 
> I've had Petr Tesarik running various mmtests, but those results are now
> invalidated due to the memory leak, and resuming them is pending some infra
> move to finish. But it might be rather non-obvious how to configure them or
> even what subset to take. I was interested in netperf and then a bit of
> everything just to see there are no unpleasant surprises.

Thanks for the update. Looking forward to the test results whenever they're
ready.

-- 
Thanks,
Hao

>