Re: [PATCH v2 2/2] sched/fair: Scan cluster before scanning LLC in wake-up path

[Gautham R. Shenoy]

On Fri, Feb 04, 2022 at 11:28:25PM +1300, Barry Song wrote:

> > We already figured out that there are no idle CPUs in this cluster. So dont
> > we gain performance by picking a idle CPU/core in the neighbouring cluster.
> > If there are no idle CPU/core in the neighbouring cluster, then it does make
> > sense to fallback on the current cluster.
> 
> What you suggested is exactly the approach we have tried at the first beginning
> during debugging. but we didn't gain performance according to benchmark, we
> were actually losing. that is why we added this line to stop ping-pong:
>          /* Don't ping-pong tasks in and out cluster frequently */
>          if (cpus_share_resources(target, prev_cpu))
>             return target;
> 
> If we delete this, we are seeing a big loss of tbench while system
> load is medium
> and above.

Thanks for clarifying this Barry. Indeed, if the workload is sensitive
to data ping-ponging across L2 clusters, this heuristic makes sense. I
was thinking of workloads that require lower tail latency, in which
case exploring the larger LLC would have made more sense, assuming
that the larger LLC has an idle core/CPU.

In the absence of any hints from the workload, like something that
Peter had previous suggested
(https://lore.kernel.org/lkml/YVwnsrZWrnWHaoqN@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/),
optimizing for cache-access seems to be the right thing to do.


> 
> Thanks
> Barry

--
Thanks and Regards
gautham.