Re: [PATCH v6] sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

* K Prateek Nayak <kprateek.nayak@amd.com> [2022-03-08 17:18:16]:

> Hello Srikar,
> 
> On 3/8/2022 2:59 PM, Srikar Dronamraju wrote:
> > [..snip..]


> >> @@ -9200,10 +9201,19 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu)
> >>  			 * Otherwise, keep the task close to the wakeup source
> >>  			 * and improve locality if the number of running tasks
> >>  			 * would remain below threshold where an imbalance is
> >> -			 * allowed. If there is a real need of migration,
> >> -			 * periodic load balance will take care of it.
> >> +			 * allowed while accounting for the possibility the
> >> +			 * task is pinned to a subset of CPUs. If there is a
> >> +			 * real need of migration, periodic load balance will
> >> +			 * take care of it.
> >>  			 */
> >> -			if (allow_numa_imbalance(local_sgs.sum_nr_running + 1, sd->imb_numa_nr))
> >> +			imb = sd->imb_numa_nr;
> >> +			if (p->nr_cpus_allowed != num_online_cpus()) {

> > Again, repeating, is the problem only happening in the pinned case?
> Yes. We've tested stream with 8 and 16 stream threads on a Zen3 system
> with 16 LLCs and in both cases, with unbound runs, we've seen each
> Stream thread get a separate LLC and we didn't observe any stacking.

If the problem is only happening with pinned case, then it means that in the
in unpinned case, the load balancer is able to do the load balancing
correctly and quickly but for some reason may not be able to do the same in
pinned case. Without the patch, even in the unpinned case, the initial CPU
range is more less the same number of LLCs as the pinned. However its able
to spread better.

I believe the problem could be in can_migrate_task() checking for
!cpumask_test_cpu(env->dst_cpu, p->cpus_ptr)

i.e dst_cpu is doing a load balance on behalf of the entire LLC, however it
only will pull tasks that can be pulled into it.

> --
> Thanks and Regards,
> Prateek

-- 
Thanks and Regards
Srikar Dronamraju