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

[Liam R. Howlett]

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.

Does the same test in processes show a regression?

Thanks,
Liam