From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Xing Zhengjun <zhengjun.xing@linux.intel.com>
Cc: Anton Blanchard <anton@au.ibm.com>,
Anton Blanchard <anton@ozlabs.org>,
Rong Chen <rong.a.chen@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Will Deacon <will@kernel.org>, paulmck <paulmck@kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
Andy Lutomirski <luto@amacapital.net>,
Andrew Morton <akpm@linux-foundation.org>,
0day robot <lkp@intel.com>, lkp <lkp@lists.01.org>,
zhengjun xing <zhengjun.xing@intel.com>,
aubrey li <aubrey.li@linux.intel.com>,
yu c chen <yu.c.chen@intel.com>
Subject: Re: [LKP] Re: [sched] bdfcae1140: will-it-scale.per_thread_ops -37.0% regression
Date: Fri, 23 Oct 2020 08:34:26 -0400 (EDT) [thread overview]
Message-ID: <496552467.36567.1603456466778.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <61ff00c3-4f55-e186-3ba7-93f96340ebd0@linux.intel.com>
----- On Oct 23, 2020, at 1:37 AM, Xing Zhengjun zhengjun.xing@linux.intel.com wrote:
> On 10/22/2020 9:19 PM, Mathieu Desnoyers wrote:
>> ----- On Oct 21, 2020, at 9:54 PM, Xing Zhengjun zhengjun.xing@linux.intel.com
>> wrote:
>> [...]
>>> In fact, 0-day just copy the will-it-scale benchmark from the GitHub, if
>>> you think the will-it-scale benchmark has some issues, you can
>>> contribute your idea and help to improve it, later we will update the
>>> will-it-scale benchmark to the new version.
>>
>> This is why I CC'd the maintainer of the will-it-scale github project, Anton
>> Blanchard.
>> My main intent is to report this issue to him, but I have not heard back from
>> him yet.
>> Is this project maintained ? Let me try to add his ozlabs.org address in CC.
>>
>>> For this test case, if we bind the workload to a specific CPU, then it
>>> will hide the scheduler balance issue. In the real world, we seldom bind
>>> the CPU...
>>
>> When you say that you bind the workload to a specific CPU, is that done
>> outside of the will-it-scale testsuite, thus limiting the entire testsuite
>> to a single CPU, or you expect that internally the will-it-scale context-switch1
>> test gets affined to a single specific CPU/core/hardware thread through use of
>> hwloc ?
>>
> The later one.
Yeah, that's not currently true due to the affinity issue I pointed out. Both threads
used in that test-case are free to be scheduled either on the same HW thread, or of
two distinct HW threads on the same core.
Depending on the choice made by the scheduler for each individual test run,
this can lead to very large variation in the benchmark results.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2020-10-23 12:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 17:25 [RFC PATCH 0/3] Membarrier updates Mathieu Desnoyers
2020-09-24 17:25 ` [RFC PATCH 1/3] sched: fix exit_mm vs membarrier (v3) Mathieu Desnoyers
2020-10-07 14:29 ` Peter Zijlstra
2020-10-07 14:57 ` Mathieu Desnoyers
2020-10-07 15:09 ` Peter Zijlstra
2020-09-24 17:25 ` [RFC PATCH 2/3] sched: membarrier: cover kthread_use_mm (v3) Mathieu Desnoyers
2020-10-02 8:33 ` [sched] bdfcae1140: will-it-scale.per_thread_ops -37.0% regression kernel test robot
2020-10-07 14:50 ` Mathieu Desnoyers
2020-10-20 3:24 ` [LKP] " Xing Zhengjun
2020-10-20 13:14 ` Mathieu Desnoyers
2020-10-22 1:54 ` Xing Zhengjun
2020-10-22 13:19 ` Mathieu Desnoyers
2020-10-23 5:37 ` Xing Zhengjun
2020-10-23 12:34 ` Mathieu Desnoyers [this message]
2020-10-07 15:07 ` [RFC PATCH 2/3] sched: membarrier: cover kthread_use_mm (v3) Peter Zijlstra
2020-10-07 15:39 ` Mathieu Desnoyers
2020-10-07 16:08 ` Peter Zijlstra
2020-10-07 16:11 ` Mathieu Desnoyers
2020-09-24 17:25 ` [RFC PATCH 3/3] sched: membarrier: document memory ordering scenarios Mathieu Desnoyers
2020-09-29 17:16 ` [RFC PATCH 0/3] Membarrier updates Mathieu Desnoyers
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=496552467.36567.1603456466778.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=anton@au.ibm.com \
--cc=anton@ozlabs.org \
--cc=aubrey.li@linux.intel.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=luto@amacapital.net \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rong.a.chen@intel.com \
--cc=will@kernel.org \
--cc=yu.c.chen@intel.com \
--cc=zhengjun.xing@intel.com \
--cc=zhengjun.xing@linux.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).