Re: [PATCH] sched, fair: Allow a small load imbalance between low utilisation SD_NUMA domains v4

[Mel Gorman]

On Mon, Jan 20, 2020 at 10:57:06PM +0530, Srikar Dronamraju wrote:
> > And this is why I'm curious as to why your workload is affected at all
> > because it uses many tasks.  I stopped allowing an imbalance for higher
> > task counts partially on the basis of your previous report.
> > 
> 
> With this hunk on top of your patch and 5 runs of numa02, there were 0
> traces.
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index ade7a8dca5e4..7506cf67bde8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8714,8 +8714,10 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
>  			 * the risk that lower domains have to be rebalanced.
>  			 */
>  			imbalance_min = 2;
> -			if (busiest->sum_nr_running <= imbalance_min)
> +			if (busiest->sum_nr_running <= imbalance_min) {
> +				trace_printk("Reseting imbalance: busiest->sum_nr_running=%d, local->sum_nr_running=%d\n", busiest->sum_nr_irunning, local->sum_nr_running);
>  				env->imbalance = 0;
> +			}
>  		}
>  
>  		return;
> 

Ok, thanks. No traces indicates that the patch should have no effect at
all and any difference in performance is a coincidence. What about the
other test programs?

> 
> perf stat for the 5 iterations this time shows: 
> 77.817 +- 0.995 seconds time elapsed  ( +-  1.28% )
> which I think is significantly less than last time around.
> 
> So I think it may be some other noise that could have contributed to the
> jump last time. Also since the time consumption of numa02 is very small, a
> small disturbance can show up as a big number from a percentage perspective.

Understood. At the moment, I'm going to assume that the patch has zero
impact on your workload but confirmation that the other test programs
trigger no traces would be appreciated.

-- 
Mel Gorman
SUSE Labs