linux-kernel - Re: [PATCH v3 2/5] sched: Take cpufreq feedback into account

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: Tue, 9 Jan 2024 15:30:51 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: linux@...linux.org.uk, catalin.marinas@....com, will@...nel.org, 
	sudeep.holla@....com, rafael@...nel.org, viresh.kumar@...aro.org, 
	agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org, 
	mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com, 
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com, 
	vschneid@...hat.com, lukasz.luba@....com, rui.zhang@...el.com, 
	mhiramat@...nel.org, daniel.lezcano@...aro.org, amit.kachhap@...il.com, 
	corbet@....net, gregkh@...uxfoundation.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, linux-doc@...r.kernel.org, 
	qyousef@...alina.io
Subject: Re: [PATCH v3 2/5] sched: Take cpufreq feedback into account

On Tue, 9 Jan 2024 at 12:22, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>
> On 08/01/2024 14:48, Vincent Guittot wrote:
> > Aggregate the different pressures applied on the capacity of CPUs and
> > create a new function that returns the actual capacity of the CPU:
> >   get_actual_cpu_capacity()
>
>    function name                scaling
>
> (1) arch_scale_cpu_capacity() - uarch
>
> (2) get_actual_cpu_capacity() - hw + cpufreq/thermal of (1)
>
> (3) capacity_of()             - rt (rt/dl/irq) of (2) (used by fair)
>
> Although (1) - (3) are very close to each other from the functional

I don't get your point as name of (1) and (3) have not been changed by the patch

> standpoint, their names are not very coherent.
>
> I assume this makes it hard to understand all of this when reading the
> code w/o knowing these patches before.
>
> Why is (2) tagged with 'actual'?

This is the actual max compute capacity of the cpu at now  i.e.
possibly reduced because of temporary frequency capping

So (2) equals (1) minus temporary performance capping and (3)
additionally subtracts the time used by other class to (2)


>
> This is especially visible in feec() where local variable cpu_cap
> relates to (3) whereas cpu_actual_cap related to (2).
>
> [...]
>