linux-kernel - Re: [linux-next:master] [fork] 6e553c6bcb: will-it-scale.per_process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231129181858.qccz6m2id4bcog73@revolver>
Date:   Wed, 29 Nov 2023 13:18:58 -0500
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     kernel test robot <oliver.sang@...el.com>
Cc:     Peng Zhang <zhangpeng.00@...edance.com>, oe-lkp@...ts.linux.dev,
        lkp@...el.com, Linux Memory Management List <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christian Brauner <brauner@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Mateusz Guzik <mjguzik@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Mike Christie <michael.christie@...cle.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        linux-kernel@...r.kernel.org, ying.huang@...el.com,
        feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linux-next:master] [fork]  6e553c6bcb:
 will-it-scale.per_process_ops 94.7% improvement

* kernel test robot <oliver.sang@...el.com> [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@intel.com
> 
> =========================================================================================
> 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