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]

Date:   Fri, 21 Feb 2020 18:05:02 +0000
From:   "Kleen, Andi" <andi.kleen@...el.com>
To:     "Tang, Feng" <feng.tang@...el.com>,
        Peter Zijlstra <peterz@...radead.org>
CC:     "Chen, Rong A" <rong.a.chen@...el.com>,
        Jiri Olsa <jolsa@...hat.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>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "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" <lkp@...ts.01.org>,
        "Huang, Ying" <ying.huang@...el.com>
Subject: RE: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops
 -5.5% regression



>So likely, this commit changes the layout of the kernel text
>and data, 

It should be only data here. text changes all the time anyways,
but data tends to be more stable.

> which may trigger some cacheline level change. From
>the system map of the 2 kernels, a big trunk of symbol's address
>changes which follow the global "pmu",

I wonder if it's the effect Andrew predicted a long time ago from
using __read_mostly. If all the __read_mostlies are moved somewhere
else the remaining read/write variables will get more sensitive to false sharing.

A simple experiment would be to add a __cacheline_aligned to align it,
and then add

____cacheline_aligned char dummy[0]; 

at the end to pad it to 64bytes.

Or hopefully Jiri can figure it out from the C2C data.

>btw, we've seen similar case that an irrelevant commit changes
>the benchmark, like a hugetlb patch improves pagefault test on
>a platform that never uses hugetlb https://lkml.org/lkml/2020/1/14/150

Yes we've had similar problems with the data segment before.

-Andi