Re: [RFC PATCH v2 0/2] sched/fair migration reduction features

[Chen Yu <yu.c.chen@intel.com>]

On 2023-10-27 at 08:57:00 +0530, K Prateek Nayak wrote:
> Hello Mathieu,
> 
> On 10/19/2023 9:35 PM, Mathieu Desnoyers wrote:
> > Hi,
> > 
> > This series introduces two new scheduler features: UTIL_FITS_CAPACITY
> > and SELECT_BIAS_PREV. When used together, they achieve a 41% speedup of
> > a hackbench workload which leaves some idle CPU time on a 192-core AMD
> > EPYC.
> > 
> > The main metrics which are significantly improved are:
> > 
> > - cpu-migrations are reduced by 80%,
> > - CPU utilization is increased by 17%.
> > 
> > Feedback is welcome. I am especially interested to learn whether this
> > series has positive or detrimental effects on performance of other
> > workloads.
> 
> I got a chance to test this series on a dual socket 3rd Generation EPYC
> System (2 x 64C/128T). Following is a quick summary:
> 
> - stream and ycsb-mongodb don't see any changes.
> 
> - hackbench and DeathStarBench see a major improvement. Both are high
>   utilization workloads with CPUs being overloaded most of the time.
>   DeathStarBench is known to benefit from lower migration count. It was
>   discussed by Gautham at OSPM '23.
> 
> - tbench, netperf, and sch bench regresses. The former two when the
>   system is near fully loaded, and the latter for most cases.

Does it mean hackbench gets benefits when the system is overloaded, while
tbench/netperf do not get benefit when the system is underloaded?

>   All these benchmarks are client-server / messenger-worker oriented and is
>   known to perform better when client-server / messenger-worker are on
>   same CCX (LLC domain).

I thought hackbench should also be of client-server mode, because hackbench has
socket/pipe mode and exchanges datas between sender/receiver.

This reminds me of your proposal to provide user hint to the scheduler
to whether do task consolidation vs task spreading, and could this also
be applied to Mathieu's case? For task or task group with "consolidate"
flag set, tasks prefer to be woken up on target/previous CPU if the wakee
fits into that CPU. In this way we could bring benefit and not introduce
regress.

thanks,
Chenyu