linux-kernel - Re: Reporting a performance regression in sched/fair on Unixbench Shell Scripts with commit a53ce18cacb4

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: <7C9D3ABF-E878-4B75-9ED6-AD6EFB6243C5@oracle.com>
Date:   Tue, 13 Jun 2023 19:35:55 +0000
From:   Saeed Mirzamohammadi <saeed.mirzamohammadi@...cle.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
CC:     Ingo Molnar <mingo@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "zhangqiao22@...wei.com" <zhangqiao22@...wei.com>
Subject: Re: Reporting a performance regression in sched/fair on Unixbench
 Shell Scripts with commit a53ce18cacb4

Hi Vincent,

> On Jun 9, 2023, at 9:52 AM, Vincent Guittot <vincent.guittot@...aro.org> wrote:
> 
> Hi Saeed,
> 
> On Fri, 9 Jun 2023 at 00:48, Saeed Mirzamohammadi
> <saeed.mirzamohammadi@...cle.com> wrote:
>> 
>> Hi all,
>> 
>> I’m reporting a regression of up to 8% with Unixbench Shell Scripts benchmarks after the following commit:
>> 
>> Commit Data:
>> commit-id        : a53ce18cacb477dd0513c607f187d16f0fa96f71
>> subject          : sched/fair: Sanitize vruntime of entity being migrated
>> author           : vincent.guittot@...aro.org
>> author date      : 2023-03-17 16:08:10
>> 
>> 
>> We have observed this on our v5.4 and v4.14 kernel and not yet tested 5.15 but I expect the same.
> 
> It would be good to confirm that the regression is present on v6.3
> where the patch has been merged originally.  It can be that there is
> hidden dependency with other patches introduced since v5.4

Regression is present on v6.3 as well, examples:
ub_gcc_224copies_Shell_Scripts_8_concurrent: ~6%
ub_gcc_224copies_Shell_Scripts_16_concurrent: ~8%
ub_gcc_448copies_Shell_Scripts_1_concurrent: ~2%
> 
> 
>> 
>> ub_gcc_1copy_Shell_Scripts_1_concurrent  :  -0.01%
>> ub_gcc_1copy_Shell_Scripts_8_concurrent  :  -0.1%
>> ub_gcc_1copy_Shell_Scripts_16_concurrent  :  -0.12%%
>> ub_gcc_56copies_Shell_Scripts_1_concurrent  :  -2.29%%
>> ub_gcc_56copies_Shell_Scripts_8_concurrent  :  -4.22%
>> ub_gcc_56copies_Shell_Scripts_16_concurrent  :  -4.23%
>> ub_gcc_224copies_Shell_Scripts_1_concurrent  :  -5.54%
>> ub_gcc_224copies_Shell_Scripts_8_concurrent  :  -8%
>> ub_gcc_224copies_Shell_Scripts_16_concurrent  :  -7.05%
>> ub_gcc_448copies_Shell_Scripts_1_concurrent  :  -6.4%
>> ub_gcc_448copies_Shell_Scripts_8_concurrent  :  -8.35%
>> ub_gcc_448copies_Shell_Scripts_16_concurrent  :  -7.09%
>> 
>> Link to unixbench:
>> github.com/kdlucas/byte-unixbench
> 
> I tried to reproduce the problem with v6.3 on my system but I don't
> see any difference with or without the patch
> 
> Do you have more details on your setup ? number of cpu and topology ?
> 
model name	: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz

Topology:
node   0   1 
  0:  10  21 
  1:  21  10 

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
CPU(s):                56
On-line CPU(s) list:   0-55
Thread(s) per core:    2
Core(s) per socket:    14
Socket(s):             2
NUMA node(s):          2

Thanks,


>> 
>> Info about benchmark:
>> "The shells scripts test measures the number of times per minute a
>>  process can start and reap a set of one, two, four and eight concurrent
>> copies of a shell scripts where the shell script applies a series of
>> transformation to a data file”
>> 
>> I have also evaluated performance before and after both of these two commits (one if fixing the other) but I still observe the same regression (C1 is still the source of regression).
>> C1. a53ce18cacb4 sched/fair: Sanitize vruntime of entity being migrated
>> C2. 829c1651e9c4 sched/fair: sanitize vruntime of entity being placed
> 
> C2 has introduced some regressions because of the case of newly
> migrated tasks that were not correctly managed and C1 fixes this
> problem. Then, both have an impact on system that runs for days  with
> low prio task
> 
> Thanks,
> Vincent
> 
> 
>> 
>> Thank you very much,
>> Saeed