linux-kernel - Re: [PATCH v2 1/2] sched/schedutil: rework performance estimation

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]

Message-ID: <83d6a790-3d18-4922-850b-b60e88761786@arm.com>
Date:   Mon, 30 Oct 2023 17:46:42 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     wyes.karny@....com, peterz@...radead.org, linux-pm@...r.kernel.org,
        rafael@...nel.org, vschneid@...hat.com, bristot@...hat.com,
        bsegall@...gle.com, rostedt@...dmis.org, dietmar.eggemann@....com,
        juri.lelli@...hat.com, beata.michalska@....com,
        linux-kernel@...r.kernel.org, qyousef@...alina.io,
        viresh.kumar@...aro.org, mingo@...hat.com, mgorman@...e.de
Subject: Re: [PATCH v2 1/2] sched/schedutil: rework performance estimation

Hi Vincent,

On 10/26/23 18:09, Vincent Guittot wrote:
> The current method to take into account uclamp hints when estimating the
> target frequency can end into situation where the selected target
> frequency is finally higher than uclamp hints whereas there are no real
> needs. Such cases mainly happen because we are currently mixing the
> traditional scheduler utilization signal with the uclamp performance
> hints. By adding these 2 metrics, we loose an important information when
> it comes to select the target frequency and we have to make some
> assumptions which can't fit all cases.
> 
> Rework the interface between the scheduler and schedutil governor in order
> to propagate all information down to the cpufreq governor.
> 
> effective_cpu_util() interface changes and now returns the actual
> utilization of the CPU with 2 optional inputs:
> - The minimum performance for this CPU; typically the capacity to handle
>    the deadline task and the interrupt pressure. But also uclamp_min
>    request when available.
> - The maximum targeting performance for this CPU which reflects the
>    maximum level that we would like to not exceed. By default it will be
>    the CPU capacity but can be reduced because of some performance hints
>    set with uclamp. The value can be lower than actual utilization and/or
>    min performance level.

You have probably missed my question in the last v1 patch set.

The description above needs a bit of clarification, since looking at the
patches some dark corners are introduced IMO:

Currently, we have a less aggressive power saving policy than this
proposal.

The questions:
What if the PD has 4 CPUs, the max util found is 500 and is from a CPU
w/ uclamp_max, but there is another CPU with normal utilization 499?
What should be the final frequency for that PD?

In current design, where we care more about 'delivered performance
to the tasks' than power saving, the +20% would be applied for the
frequency. Therefore if that CPU with 499 util doesn't have uclamp_max,
it would get a decent amount of idle time for its tasks (to compensate
some workload variation).

Regards,
Lukasz