From: Feng Tang <feng.tang@intel.com> To: Linus Torvalds <torvalds@linux-foundation.org> 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: Tue, 25 Feb 2020 12:53:49 +0800 [thread overview] Message-ID: <20200225045349.GD63065@shbuild999.sh.intel.com> (raw) In-Reply-To: <CAHk-=wisa2xZHaCV=kh3seU-1kFDTjyWW9Ak3w5HH8nDvv7Snw@mail.gmail.com> Hi Linus, On Mon, Feb 24, 2020 at 07:15:15PM -0800, Linus Torvalds wrote: > 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. I thought that too. Since we have the reproducable platform, we will keep an eye on it, and report back if anything found. You've mentioned the patch's effect on small system in another mail, I ran the benchmark on a 4 core Skylake desktop, and it only brought 2% performance gain, as expected. > > 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. I'll try to reach some silicon people, and get back if found anything. > 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. Thanks again for the patch. - Feng > > If you fix the details on all the microbenchmarks you find, eventually > you probably do well on real loads too.. > > Linus
WARNING: multiple messages have this Message-ID (diff)
From: Feng Tang <feng.tang@intel.com> To: lkp@lists.01.org Subject: Re: [perf/x86] 81ec3f3c4c: will-it-scale.per_process_ops -5.5% regression Date: Tue, 25 Feb 2020 12:53:49 +0800 [thread overview] Message-ID: <20200225045349.GD63065@shbuild999.sh.intel.com> (raw) In-Reply-To: <CAHk-=wisa2xZHaCV=kh3seU-1kFDTjyWW9Ak3w5HH8nDvv7Snw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1987 bytes --] Hi Linus, On Mon, Feb 24, 2020 at 07:15:15PM -0800, Linus Torvalds wrote: > 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. I thought that too. Since we have the reproducable platform, we will keep an eye on it, and report back if anything found. You've mentioned the patch's effect on small system in another mail, I ran the benchmark on a 4 core Skylake desktop, and it only brought 2% performance gain, as expected. > > 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. I'll try to reach some silicon people, and get back if found anything. > 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. Thanks again for the patch. - Feng > > If you fix the details on all the microbenchmarks you find, eventually > you probably do well on real loads too.. > > Linus
next prev parent reply other threads:[~2020-02-25 4:53 UTC|newest] Thread overview: 57+ 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:32 ` kernel test robot 2020-02-05 12:58 ` Peter Zijlstra 2020-02-05 12:58 ` Peter Zijlstra 2020-02-06 3:04 ` [LKP] " Li, Philip 2020-02-06 3:04 ` Li, Philip 2020-02-21 8:03 ` [LKP] " Feng Tang 2020-02-21 8:03 ` Feng Tang 2020-02-21 10:58 ` [LKP] " Peter Zijlstra 2020-02-21 10:58 ` Peter Zijlstra 2020-02-21 13:20 ` [LKP] " Jiri Olsa 2020-02-21 13:20 ` Jiri Olsa 2020-02-23 14:11 ` [LKP] " Feng Tang 2020-02-23 14:11 ` Feng Tang 2020-02-23 17:37 ` [LKP] " Linus Torvalds 2020-02-23 17:37 ` Linus Torvalds 2020-02-24 0:33 ` [LKP] " Feng Tang 2020-02-24 0:33 ` Feng Tang 2020-02-24 1:06 ` [LKP] " Linus Torvalds 2020-02-24 1:06 ` Linus Torvalds 2020-02-24 1:58 ` [LKP] " Huang, Ying 2020-02-24 1:58 ` Huang, Ying 2020-02-24 2:19 ` [LKP] " Feng Tang 2020-02-24 2:19 ` Feng Tang 2020-02-24 13:20 ` [LKP] " Feng Tang 2020-02-24 13:20 ` Feng Tang 2020-02-24 19:24 ` [LKP] " Linus Torvalds 2020-02-24 19:24 ` Linus Torvalds 2020-02-24 19:42 ` [LKP] " Kleen, Andi 2020-02-24 19:42 ` Kleen, Andi 2020-02-24 20:09 ` [LKP] " Linus Torvalds 2020-02-24 20:09 ` Linus Torvalds 2020-02-24 20:47 ` [LKP] " Linus Torvalds 2020-02-24 20:47 ` Linus Torvalds 2020-02-24 21:20 ` [LKP] " Eric W. Biederman 2020-02-24 21:20 ` Eric W. Biederman 2020-02-24 21:43 ` [LKP] " Linus Torvalds 2020-02-24 21:43 ` Linus Torvalds 2020-02-24 21:59 ` [LKP] " Eric W. Biederman 2020-02-24 21:59 ` Eric W. Biederman 2020-02-24 22:12 ` [LKP] " Linus Torvalds 2020-02-24 22:12 ` Linus Torvalds 2020-02-25 2:57 ` [LKP] " Feng Tang 2020-02-25 2:57 ` Feng Tang 2020-02-25 3:15 ` [LKP] " Linus Torvalds 2020-02-25 3:15 ` Linus Torvalds 2020-02-25 4:53 ` Feng Tang [this message] 2020-02-25 4:53 ` Feng Tang 2020-02-23 19:36 ` [LKP] " Jiri Olsa 2020-02-23 19:36 ` Jiri Olsa 2020-02-24 1:14 ` Feng Tang 2020-02-21 18:05 ` [LKP] " Kleen, Andi 2020-02-21 18:05 ` Kleen, Andi 2020-02-22 12:43 ` [LKP] " Feng Tang 2020-02-22 12:43 ` Feng Tang 2020-02-22 17:08 ` [LKP] " Kleen, Andi 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=20200225045349.GD63065@shbuild999.sh.intel.com \ --to=feng.tang@intel.com \ --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=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=torvalds@linux-foundation.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.