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  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, 25 Aug 2020 13:20:57 +0530
From:   Viresh Kumar <>
To:     Ionela Voinescu <>
Subject: Re: [PATCH v3 5/5] arch_topology, arm, arm64: define

On 24-08-20, 22:02, Ionela Voinescu wrote:
> From: Valentin Schneider <>
> arch_scale_freq_invariant() is used by schedutil to determine whether
> the scheduler's load-tracking signals are frequency invariant. Its
> definition is overridable, though by default it is hardcoded to 'true'
> if arch_scale_freq_capacity() is defined ('false' otherwise).
> This behaviour is not overridden on arm, arm64 and other users of the
> generic arch topology driver, which is somewhat precarious:
> arch_scale_freq_capacity() will always be defined, yet not all cpufreq
> drivers are guaranteed to drive the frequency invariance scale factor
> setting. In other words, the load-tracking signals may very well *not*
> be frequency invariant.
> Now that cpufreq can be queried on whether the current driver is driving
> the Frequency Invariance (FI) scale setting, the current situation can
> be improved. This combines the query of whether cpufreq supports the
> setting of the frequency scale factor, with whether all online CPUs are
> counter-based FI enabled.
> While cpufreq FI enablement applies at system level, for all CPUs,
> counter-based FI support could also be used for only a subset of CPUs to
> set the invariance scale factor. Therefore, if cpufreq-based FI support
> is present, we consider the system to be invariant. If missing, we
> require all online CPUs to be counter-based FI enabled in order for the
> full system to be considered invariant.
> If the system ends up not being invariant, a new condition is needed in
> the counter initialization code that disables all scale factor setting
> based on counters.
> Precedence of counters over cpufreq use is not important here. The
> invariant status is only given to the system if all CPUs have at least
> one method of setting the frequency scale factor.
> Signed-off-by: Valentin Schneider <>
> Signed-off-by: Ionela Voinescu <>
> Acked-by: Catalin Marinas <>
> Cc: Catalin Marinas <>
> Cc: Will Deacon <>
> Cc: Sudeep Holla <>
> ---
>  arch/arm/include/asm/topology.h   | 1 +
>  arch/arm64/include/asm/topology.h | 1 +
>  arch/arm64/kernel/topology.c      | 7 +++++++
>  drivers/base/arch_topology.c      | 6 ++++++
>  include/linux/arch_topology.h     | 2 ++
>  5 files changed, 17 insertions(+)
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index e0593cf095d0..9219e67befbe 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -9,6 +9,7 @@
>  /* Replace task scheduler's default frequency-invariant accounting */
>  #define arch_scale_freq_capacity topology_get_freq_scale
> +#define arch_scale_freq_invariant topology_scale_freq_invariant

Maybe this macro should have been named arch_is_freq_invariant as all other ones
are actually getting us a scaled number and this one is just a flag. But yeah,
that is out of this series's scope, but maybe you should name
topology_scale_freq_invariant() to topology_is_freq_invariant() or something
else on those lines ? Anyway:

Acked-by: Viresh Kumar <>


Powered by blists - more mailing lists