Re: [PATCH v3 26/30] maple_tree: Use maple copy node for mas_wr_split()

[D, Suneeth]

On 5/9/2026 2:48 AM, Liam R. Howlett wrote:
> [You don't often get email from liam@xxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 26/05/08 02:12PM, D, Suneeth wrote:
> > Hi Liam Howlett,
> >
> > On 1/31/2026 2:29 AM, Liam R. Howlett wrote:
> > > Instead of using the maple big node, use the maple copy node for reduced
> > > stack usage and aligning with mas_wr_rebalance() and
> > > mas_wr_spanning_store().
> > >
> > > Splitting a node is similar to rebalancing, but a new evaluation of when
> > > to ascend is needed.  The only other difference is that the data is
> > > pushed and never rebalanced at each level.
> > >
> > > The testing must also align with the changes to this commit to ensure
> > > the test suite continues to pass.
> >
> > We run will-it-scale micro-benchmark as part of our weekly CI for Kernel
> > Performance Regression testing between a stable vs rc kernel. We
> > observed will-it-scale-thread-brk1 variant was regressing with
> > ~9% on an AMD's Turin machine between the kernels v7.0 and
> > v7.1-rc1. Bisecting further landed me onto this commit
> > 280b792cac62ddadca2935766ca870b438c86323 (maple_tree: Use maple copy node
> > for mas_wr_split()) as the first bad
> > commit. The following were the machine's configuration and test
> > parameters used:-
> >
> > Model name:           AMD EPYC 64-Core Processor [Turin]
> > Thread(s) per core:   2
> > Core(s) per socket:   64
> > Socket(s):            2
> > Total online memory:  258G
> >
> > Test params:
> > ------------
> >
> > nr_task: [1 8 64 128 192 256]
> >        mode: thread
> >        test: brk1
> >        kpi: per_thread_ops
> >        cpufreq_governor: performance
> >
> > The following are the stats after bisection:-
> > (the KPI used here is per_thread_ops)
> >
> > v7.0 (baseline)  %diff   per_process_ops   kernel_rc_ver
> > ---------------  -----   ---------------   -------------
> > 353091            -9     321987            v7.1-rc1
> > 353091            -7     328897          v7.0-rc5-280b792cac62(culprit)
> > 353091            -1     347884        v7.0-rc5-11e7f22f5e85(culpritm1)
> >
> > jFYI a very high level call trace from running will-it-scale-thread-brk1
> > which ends up in mas_wr_split goes like this,
> >
> > do_brk_flags() {
> >    may_expand_vm();
> >    vma_merge_new_range() {
> >      vma_expand() {
> >        commit_merge() {
> >          vma_iter_store_overwrite(){
> >            mas_store_prealloc(){
> >              mas_wr_store_entry(){
> >                mas_wr_split();  <--- Function of interest from this patch
> >              } /* mas_wr_store_entry */
> >            } /* mas_store_prealloc */
> >          } /* vma_iter_store_overwrite */
> >        } /* commit_merge */
> >      } /* vma_expand */
> > } /* do_brk_flags */
> >
> > Recreation steps:
> > -----------------
> >
> > 1) git clone https://github.com/antonblanchard/will-it-scale.git
> > 2) git clone https://github.com/intel/lkp-tests.git
> > 3) cd will-it-scale && git apply
> > lkp-tests/programs/will-it-scale/pkg/will-it-scale.patch
> > 4) make
> > 5) python3 ./runtest.py brk1 25 thread 0 0 1 8 64 128 192 256
> >
> > NOTE: [5] is specific to machine's architecture. starting from 1 is the
> > array of no.of tasks that you'd wish to run the testcase which here is
> > no.cores per CCX, per NUMA node/ per Socket, nr_threads.
> >
> > Would be happy to help with further testing and providing additional
> > data if required.
>
> Thank you for this report.
>
> Considering this is brk1() in thread mode, I'm going to tell you that
> this test is seriously flawed and will not produce anything that looks
> reasonable.  The way it is written will race all over the place and thus
> is unreliable.

Thank you Liam and Matthew for your candid feedback. You're right that I 
should have reasoned about what brk1 in thread mode is actually 
measuring before treating the bisected delta as a real regression.

> Does the same test in processes show a regression?

No, the same test in process does not show a significant regression.

v7.0 (baseline)  %diff   per_process_ops   kernel_rc_ver
---------------  -----   ---------------   -------------
1050189            -2     1027859            v7.1-rc1

Apologies for the noise, and thanks again for your time.

> Thanks,
> Liam

Thanks & Regards,
Suneeth D