Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Kleen, Andi" <andi.kleen@intel.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        "Tang, Feng" <feng.tang@intel.com>
CC:     Jiri Olsa <jolsa@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "Chen, Rong A" <rong.a.chen@intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        "Vince Weaver" <vincent.weaver@maine.edu>,
        Jiri Olsa <jolsa@kernel.org>,
        "Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
        Ravi Bangoria <ravi.bangoria@linux.ibm.com>,
        Stephane Eranian <eranian@google.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        "lkp@lists.01.org" <lkp@lists.01.org>,
        "Huang, Ying" <ying.huang@intel.com>
Subject: RE: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops
 -5.5% regression
Thread-Topic: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops
 -5.5% regression
Thread-Index: AQHV60gfK6eA3q3jR0u6sMXxx2rr5qgqvXYq
Date:   Mon, 24 Feb 2020 19:42:45 +0000
Message-ID: <E8ECBC65D0B2554DAD44EBE43059B3740F2AA1@ORSMSX110.amr.corp.intel.com>
References: <20200205123216.GO12867@shao2-debian>
 <20200205125804.GM14879@hirez.programming.kicks-ass.net>
 <20200221080325.GA67807@shbuild999.sh.intel.com>
 <20200221132048.GE652992@krava>
 <20200223141147.GA53531@shbuild999.sh.intel.com>
 <CAHk-=wjKFTzfDWjAAabHTZcityeLpHmEQRrKdTuk0f4GWcoohQ@mail.gmail.com>
 <20200224003301.GA5061@shbuild999.sh.intel.com>
 <CAHk-=whi87NNOnNXJ6CvyyedmhnS8dZA2YkQQSajvBArH5XOeA@mail.gmail.com>
 <20200224021915.GC5061@shbuild999.sh.intel.com>,<CAHk-=wjkSb1OkiCSn_fzf2v7A=K0bNsUEeQa+06XMhTO+oQUaA@mail.gmail.com>
In-Reply-To: <CAHk-=wjkSb1OkiCSn_fzf2v7A=K0bNsUEeQa+06XMhTO+oQUaA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

>Does anybody else have any ideas?

We've had problems with atomics having strange ordering constraints before.

But it might be c2c missing the right cache line. There are some known cases where that can happen.

Feng, can you double check with 

perf record -a -d -e mem_load_l3_hit_retired.xsnp_hitm:pp,mem_load_l3_miss_retired.remote_hitm:pp ...

Does it report the same hot IPs as c2c?
What's the break down between the first and the second event for the hot IPs? The first is inside socket, the second between sockets.

-Andi