linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Hao Li <hao.li@linux.dev>
Cc: kernel test robot <oliver.sang@intel.com>,
	oe-lkp@lists.linux.dev, lkp@intel.com, linux-mm@kvack.org,
	Harry Yoo <harry.yoo@oracle.com>,
	Mateusz Guzik <mjguzik@gmail.com>,
	Petr Tesarik <ptesarik@suse.com>
Subject: Re: [vbabka:b4/sheaves-for-all-rebased] [slab] aa8fdb9e25: will-it-scale.per_process_ops 46.5% regression
Date: Thu, 29 Jan 2026 09:47:02 +0100	[thread overview]
Message-ID: <3317345a-47c9-4cbb-9785-f05d19e09303@suse.cz> (raw)
In-Reply-To: <rsfdl2u4zjec5s4f46ubsr3phjkdhq4jajgwimbml7mq6yy2lg@krjc6oobmkwz>

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.

> - 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.

> 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.



  reply	other threads:[~2026-01-29  8:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13 13:57 kernel test robot
2026-01-28 10:31 ` Vlastimil Babka
2026-01-29  7:05   ` Hao Li
2026-01-29  8:47     ` Vlastimil Babka [this message]
2026-01-29 14:49       ` Hao Li
2026-01-30  1:24   ` Oliver Sang

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=3317345a-47c9-4cbb-9785-f05d19e09303@suse.cz \
    --to=vbabka@suse.cz \
    --cc=hao.li@linux.dev \
    --cc=harry.yoo@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mjguzik@gmail.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=ptesarik@suse.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