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:   Thu, 28 Oct 2021 08:16:28 +0100
From:   Lukasz Luba <>
To:     Bjorn Andersson <>
Subject: Re: [PATCH v2 1/5] arch_topology: Introduce thermal pressure update

On 10/27/21 7:43 PM, Bjorn Andersson wrote:
> On Fri 15 Oct 07:45 PDT 2021, Lukasz Luba wrote:
>> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> [..]
>> +/**
>> + * topology_thermal_pressure_update() - Update thermal pressure for CPUs
>> + * @cpus	: The related CPUs for which capacity has been reduced
>> + * @capped_freq	: The maximum allowed frequency that CPUs can run at
> I know this matches what I see in e.g. the Qualcomm cpufreq hw driver,
> but in what cases will @capped_freq differ from
> cpufreq_get_hw_max_freq(cpumask_first(cpus))?

The @capped_freq is the maximum allowed frequency value due to
thermal reasons, which will always be lower or equal to the value
returned by cpufreq_get_hw_max_freq()
(effectively: 'policy->cpuinfo.max_freq').

We limit the frequency (and voltage) of CPU to reduce power (and heat)
in the passive cooling system. That information is important to us,
because scheduler needs to know how fast the CPU can go. It cannot
assume that the speed is always 'policy->cpuinfo.max_freq'. Often
it's less then that at heavy load or GPU heavy load (the same SoC).


Powered by blists - more mailing lists