Re: [PATCH] sched/fair: Fix task utilization accountability in cpu_util_next()

[Quentin Perret <qperret@google.com>]

On Monday 22 Feb 2021 at 11:36:03 (+0000), Vincent Donnefort wrote:
> Here's with real life numbers.
> 
> The task: util_avg=3 (1) util_est=11 (2)
> 
> pd0 (CPU-0, CPU-1, CPU-2)
> 
>  cpu_util_next(CPU-0, NULL): 7
>  cpu_util_next(CPU-1, NULL): 3
>  cpu_util_next(CPU-2, NULL): 0 <- Most capacity, try to place task here.
> 
>  cpu_util_next(CPU-2, task): 0 + 11 (2)
> 
> 
> pd1 (CPU-3):
> 
>  cpu_util_next(CPU-3, NULL): 77
> 
>  cpu_util_next(CPU-3, task): 77 + 3 (1)
> 
> 
> On pd0, the task contribution is 11. On pd1, it is 3.

Yes but that accurately reflects what the task's impact on frequency
selection of those CPUs if it was enqueued there, right?

This is an important property we should aim to keep, the frequency
prediction needs to be in sync with the actual frequency request, or
the energy estimate will be off.

> When computing the energy
> deltas, pd0's is likely to be higher than pd1's, only because the task
> contribution is higher for one comparison than the other.

You mean the contribution to sum_util right? I think I see what you mean
but I'm still not sure if this really is an issue. This is how util_est
works, and the EM stuff is just consistent with that.

The issue you describe can only happen (I think) when a rq's util_avg is
larger than its util-est emwa by some margin (that has to do with the
ewma-util_avg delta for the task?). But that means the ewma is not to be
trusted to begin with, so ...