linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Feng Tang <feng.tang@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	kernel test robot <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, andi.kleen@intel.com, "Huang,
	Ying" <ying.huang@intel.com>
Subject: Re: [LKP] Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops -5.5% regression
Date: Mon, 24 Feb 2020 19:15:15 -0800	[thread overview]
Message-ID: <CAHk-=wisa2xZHaCV=kh3seU-1kFDTjyWW9Ak3w5HH8nDvv7Snw@mail.gmail.com> (raw)
In-Reply-To: <20200225025748.GB63065@shbuild999.sh.intel.com>

On Mon, Feb 24, 2020 at 6:57 PM Feng Tang <feng.tang@intel.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

  reply	other threads:[~2020-02-25  3:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 12:32 [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops -5.5% regression kernel test robot
2020-02-05 12:58 ` Peter Zijlstra
2020-02-06  3:04   ` [LKP] " Li, Philip
2020-02-21  8:03   ` Feng Tang
2020-02-21 10:58     ` Peter Zijlstra
2020-02-21 13:20     ` Jiri Olsa
2020-02-23 14:11       ` Feng Tang
2020-02-23 17:37         ` Linus Torvalds
2020-02-24  0:33           ` Feng Tang
2020-02-24  1:06             ` Linus Torvalds
2020-02-24  1:58               ` Huang, Ying
2020-02-24  2:19               ` Feng Tang
2020-02-24 13:20                 ` Feng Tang
2020-02-24 19:24                 ` Linus Torvalds
2020-02-24 19:42                   ` Kleen, Andi
2020-02-24 20:09                   ` Linus Torvalds
2020-02-24 20:47                     ` Linus Torvalds
2020-02-24 21:20                       ` Eric W. Biederman
2020-02-24 21:43                         ` Linus Torvalds
2020-02-24 21:59                           ` Eric W. Biederman
2020-02-24 22:12                             ` Linus Torvalds
2020-02-25  2:57                       ` Feng Tang
2020-02-25  3:15                         ` Linus Torvalds [this message]
2020-02-25  4:53                           ` Feng Tang
2020-02-23 19:36         ` Jiri Olsa
2020-02-21 18:05     ` Kleen, Andi
2020-02-22 12:43       ` Feng Tang
2020-02-22 17:08         ` Kleen, Andi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wisa2xZHaCV=kh3seU-1kFDTjyWW9Ak3w5HH8nDvv7Snw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andi.kleen@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=eranian@google.com \
    --cc=feng.tang@intel.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@lists.01.org \
    --cc=mingo@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rong.a.chen@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.weaver@maine.edu \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).