----- On Oct 23, 2020, at 1:37 AM, Xing Zhengjun zhengjun.xing(a)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(a)linux.intel.com
>> 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
> 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.