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-next>] [day] [month] [year] [list]
Message-Id: <20200924123016.13427-1-ionela.voinescu@arm.com>
Date:   Thu, 24 Sep 2020 13:30:14 +0100
From:   Ionela Voinescu <ionela.voinescu@....com>
To:     catalin.marinas@....com, sudeep.holla@....com, will@...nel.org,
        linux@...linux.org.uk, rjw@...ysocki.net, viresh.kumar@...aro.org
Cc:     dietmar.eggemann@....com, valentin.schneider@....com,
        linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, ionela.voinescu@....com
Subject: [PATCH 0/2]cpufreq,topology,arm: disable FI for BL_SWITCHER

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@arm.com/
[2] https://lore.kernel.org/lkml/20200722093732.14297-4-ionela.voinescu@arm.com/
[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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ