[PATCH 0/2]cpufreq,topology,arm: disable FI for BL_SWITCHER
From: Ionela Voinescu
Date: Thu Sep 24 2020 - 08:30:46 EST
This series is the result of the discussions ([1], [2]) around the
complications that the BL_SWITCHER poses when it comes to Frequency
Invariance (FI) and it aims to restart the discussions.
To properly scale its per-entity load-tracking signals, the task
scheduler needs to be given a frequency scale factor, i.e. some image of
the current frequency the CPU is running at, relative to its maximum
frequency.
But (reiterating the message in the changelog of patch 2/2), big.LITTLE
switching complicates the setting of a correct cpufreq-based frequency
invariance scale factor due to (as observed in
drivers/cpufreq/vexpress-spc-cpufreq.c):
- Incorrect current and maximum frequencies as a result of the
exposure of a virtual frequency table to the cpufreq core,
- Missed updates as a result of asynchronous frequency adjustments
caused by frequency changes in other CPU pairs.
More information on this feature can be found at [3].
Given that its functionality is atypical in regards to FI and that this
is an old technology, patch 2/2 disable FI for when big.LITTLE switching
is configured in to prevent incorrect scale setting.
For this purpose patch 1/2 changes the way arch_set_freq_scale() is
defined in architecture code which brings it in line with the logic of
other architectural function definitions while allowing for less invasive
filtering of FI support.
In the discussions at [2], three possible solutions were suggested:
- (1) conditioning FI by !CONFIG_BL_SWITCHER
- (2) leave as is with note in driver specifying this FI broken
functionality
- (3) removing full BL_SWITCHER support
This series restructures the solution at (1). The reason for it is that
the new patch limits the ifdef filtering to the arm topology include file,
a location where frequency invariance functions are defined. Therefore,
this seems more appropriate given that the b.L switcher is an arm
technology and that the new FI filtering location seems more natural for
conditioned FI disabling.
Solutions (2) and (3) were not implemented given that there might be some
remaining users of this technology (Samsung Chromebook 2 - Samsung Exynos
5 Octa 5420, Samsung Exynos 5 Octa 5800) and therefore leaving this
broken (2) seems equally bad to removing support for it (3).
[1] https://lore.kernel.org/lkml/20200701090751.7543-5-ionela.voinescu@xxxxxxx/
[2] https://lore.kernel.org/lkml/20200722093732.14297-4-ionela.voinescu@xxxxxxx/
[3] https://lwn.net/Articles/481055/
Many thanks,
Ionela.
Ionela Voinescu (2):
cpufreq,arm,arm64: restructure definitions of arch_set_freq_scale()
arm: disable frequency invariance for CONFIG_BL_SWITCHER
arch/arm/include/asm/topology.h | 4 ++++
arch/arm64/include/asm/topology.h | 1 +
drivers/base/arch_topology.c | 4 ++--
drivers/cpufreq/cpufreq.c | 7 -------
include/linux/arch_topology.h | 2 ++
include/linux/cpufreq.h | 11 ++++++++---
6 files changed, 17 insertions(+), 12 deletions(-)
--
2.17.1