linux-kernel - Re: [LKP] Re: [perf/x86] 81ec3f3c4c: 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: <CAHk-=wisa2xZHaCV=kh3seU-1kFDTjyWW9Ak3w5HH8nDvv7Snw@mail.gmail.com>
Date:   Mon, 24 Feb 2020 19:15:15 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Feng Tang <feng.tang@...el.com>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        kernel test robot <rong.a.chen@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Vince Weaver <vincent.weaver@...ne.edu>,
        Jiri Olsa <jolsa@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        Ravi Bangoria <ravi.bangoria@...ux.ibm.com>,
        Stephane Eranian <eranian@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        andi.kleen@...el.com, "Huang, Ying" <ying.huang@...el.com>
Subject: Re: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops
 -5.5% regression

On Mon, Feb 24, 2020 at 6:57 PM Feng Tang <feng.tang@...el.com> wrote:
>
> Thanks for the optimization patch for signal!
>
> It makes a big difference, that the performance score is tripled!
> bump from original 17000 to 54000. Also the gap between 5.0-rc6 and
> 5.0-rc6+Jiri's patch is reduced to around 2%.

Ok, so what I think is happening is that the exact same issue still
exists, but now with less contention it's not quite as noticeable.

Can you find some Intel CPU hardware person who could spend a moment
on that odd 32-byte sub-block issue?

Considering that this effect apparently doesn't happen on any other
platform you've tested, and this Cascade Lake platform is the newly
released current Intel server platform, I think it's worth looking at.

That microbenchmark is not important on its own, but the odd timing
behaviour it has would be good to have explained.

And while the signal sending microbenchmark is not likely to be very
relevant to much anything else, I guess I'll apply the patch. Even if
it's just a microbenchmark, it's not like we haven't used those before
to pinpoint some very specific behavior. We used lmbench (and whatever
that odd page cache benchmark was) to do some fairly fundamental
optimizations back in the days.

If you fix the details on all the microbenchmarks you find, eventually
you probably do well on real loads too..

           Linus