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 10:11:03 +0000
From:   Quentin Perret <qperret@...gle.com>
To:     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()

Hey Vincent,

On Monday 22 Feb 2021 at 09:54:01 (+0000), vincent.donnefort@....com wrote:
> From: Vincent Donnefort <vincent.donnefort@....com>
> 
> Currently, cpu_util_next() estimates the CPU utilization as follows:
> 
>   max(cpu_util + task_util,
>       cpu_util_est + task_util_est)

s/task_util_est/_task_util_est

This is an important difference.

> 
> This is an issue when making a comparison between CPUs, as the task
> contribution can be either:
> 
>   (1) task_util_est, on a mostly idle CPU, where cpu_util is close to 0
>       and task_util_est > cpu_util.
>   (2) task_util, on a mostly busy CPU, where cpu_util > task_util_est.

I don't understand how this is an issue, this is by design with util-est
no?

Note that cpu_util_next() tries to accurately predict what cpu_util(@cpu)
will be once @p is enqueued on @dst_cpu. There should be no policy
decision here, we just reproduce the enqueue aggreagation -- see
util_est_enqueue() and cpu_util().

Could you please give an example where you think cpu_util_next()
computes the wrong value?

Thanks,
Quentin