[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba2cd83a-7c3b-9f75-2413-a0ef3ed463d3@linaro.org>
Date: Thu, 1 Aug 2019 15:00:10 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Quentin Perret <quentin.perret@....com>, edubezval@...il.com,
rui.zhang@...el.com, javi.merino@...nel.org,
viresh.kumar@...aro.org, amit.kachhap@...il.com, rjw@...ysocki.net,
catalin.marinas@....com, will@...nel.org
Cc: dietmar.eggemann@....com, ionela.voinescu@....com,
mka@...omium.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v6 0/3] Make IPA use PM_EM
Hi Rui,
is it possible to merge these patches? They are acked-by since May.
Thanks
-- Daniel
On 01/08/2019 14:46, Quentin Perret wrote:
> Changes in v6
> *************
> - Added Daniel's and Viresh's Acked-by to all patches
>
> Changes in v5:
> **************
> - Changed patch 02 to guard IPA-specific code in cpu_cooling.c with
> appropriate ifdefery (Daniel)
> - Rebased on 5.2-rc2
>
> Changes in v4:
> **************
> - Added Viresh's Acked-by to all 3 patches
> - Improved commit message of patch 3/3 to explain how it has no
> functional impact on existing users (Eduardo)
>
> Changes in v3:
> **************
> - Changed warning message for unordered tables to something more
> explicit (Viresh)
> - Changed WARN() into a pr_err() for consistency
>
> Changes in v2:
> **************
> - Fixed patch 01/03 to actually enable CONFIG_ENERGY_MODEL
> - Added "depends on ENERGY_MODEL" to IPA (Daniel)
> - Added check to bail out if the freq table is unsorted (Viresh)
>
> Cover letter:
> *************
>
> The Intelligent Power Allocator (IPA) thermal governor uses an Energy
> Model (or EM) of the CPUs to re-distribute the power budget. To do so,
> it builds a table of <frequency, power> tuples where the power values
> are computed using the 'dynamic-power-coefficient' DT property. All of
> this is done in and only for the thermal subsystem, and more
> specifically for CPUs -- the power of other types of devices is obtained
> differently.
>
> Recently, the CPU scheduler has seen the introduction of Energy Aware
> Scheduling (EAS) patches, which also rely on an EM of the CPUs. This EM,
> however, is managed by an independent framework, called PM_EM, aimed to
> be used by all kernel subsystems interested in the power consumed by
> CPUs, and not only the scheduler.
>
> This patch series follows this logic and removes the (now redundant)
> thermal-specific EM computation code to migrate IPA to use PM_EM
> instead.
>
> Doing so should have no visible functional impact for existing users of
> IPA since:
>
> - during the 5.1 development cycle, a series of patches [1] introduced
> in PM_OPP some infrastructure (dev_pm_opp_of_register_em()) enabling
> the registration of EMs in PM_EM using the DT property used by IPA;
>
> - the existing upstream cpufreq drivers marked with the
> 'CPUFREQ_IS_COOLING_DEV' flag all call dev_pm_opp_of_register_em(),
> which means they all support PM_EM (the only two exceptions are
> qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which
> already supports PM_EM without using the PM_OPP infrastructurei
> because it read power costs directly from firmware);
>
> So, migrating IPA to using PM_EM should effectively be just plumbing
> since for the existing IPA users the PM_EM tables will contain the
> exact same power values that IPA used to compute on its own until now.
> The only new dependency is to compile in CONFIG_ENERGY_MODEL.
>
> Why is this migration still a good thing ? For three main reasons.
>
> 1. it removes redundant code;
>
> 2. it introduces an abstraction layer between IPA and the EM
> computation. PM_EM offers to EAS and IPA (and potentially other
> clients) standardized EM tables and hides 'how' these tables have
> been obtained. PM_EM as of now supports power values either coming
> from the 'dynamic-power-coefficient' DT property or obtained
> directly from firmware using SCMI. The latter is a new feature for
> IPA and that comes 'for free' with the migration. This will also be
> true in the future every time PM_EM gets support for other ways of
> loading the EM. Moreover, PM_EM is documented and has a debugfs
> interface which should help adding support for new platforms.
>
> 3. it builds a consistent view of the EM of CPUs across kernel
> subsystems, which is a pre-requisite for any kind of future work
> aiming at a smarter power allocation using scheduler knowledge about
> the system for example.
>
> [1] https://lore.kernel.org/lkml/20190204110952.16025-1-quentin.perret@arm.com/
>
>
> Quentin Perret (3):
> arm64: defconfig: Enable CONFIG_ENERGY_MODEL
> thermal: cpu_cooling: Make the power-related code depend on IPA
> thermal: cpu_cooling: Migrate to using the EM framework
>
> arch/arm64/configs/defconfig | 1 +
> drivers/thermal/Kconfig | 1 +
> drivers/thermal/cpu_cooling.c | 428 ++++++++++++++--------------------
> 3 files changed, 178 insertions(+), 252 deletions(-)
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists