* kernel test robot <oliver.sang@xxxxxxxxx> [231128 08:56]:
>
>
> Hello,
>
> kernel test robot noticed a 94.7% improvement of will-it-scale.per_process_ops on:
Okay, this *seems* awesome. I expected to see results in
micro-benchmarks from Peng's patches - but not in this area.
>
>
> commit: 6e553c6bcb7746abad29ce63e0cb7a18348e88fb ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> testcase: will-it-scale
> test machine: 104 threads 2 sockets (Skylake) with 192G memory
> parameters:
>
> nr_task: 100%
> mode: process
> test: brk2
> cpufreq_governor: performance
>
>
>
>
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20231128/202311282145.ff13737b-oliver.sang@xxxxxxxxx
>
> =========================================================================================
> compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
> gcc-12/performance/x86_64-rhel-8.3/process/100%/debian-11.1-x86_64-20220510.cgz/lkp-skl-fpga01/brk2/will-it-scale
This test was written by willy to improve on the less-than-ideal bkr1;
forking has nothing to do with this test. It is expanding and
contracting a VMA (as apposed to adding and removing a new VMA in brk1).
[1]
The forking changes should have zero effects on this test. Does anyone
have an insight as to why we would see any change (let alone 94.7%)?
I would think that maybe the start-up time would change, but that should
be a very small amount of the tests overall time.
>
> commit:
> ec81deb6b7 ("maple_tree: preserve the tree attributes when destroying maple tree")
The tree isn't destroyed in this test.
> 6e553c6bcb ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()")
The process isn't forking in the loop.
...
1. https://github.com/antonblanchard/will-it-scale/blame/master/tests/brk2.c
Thanks,
Liam
