linux-kernel - Re: [PATCH] sched/fair: Fix task utilization accountability in cpu_util

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Feb 2021 12:23:04 +0000
From:   Quentin Perret <qperret@...gle.com>
To:     Vincent Donnefort <vincent.donnefort@....com>
Cc:     peterz@...radead.org, mingo@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, linux-kernel@...r.kernel.org,
        patrick.bellasi@...bug.net, valentin.schneider@....com
Subject: Re: [PATCH] sched/fair: Fix task utilization accountability in
 cpu_util_next()

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 ...