Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Wed, 24 May 2023 19:25:06 +0200 | Subject | Re: [PATCH v2 00/17] Introduce runtime modifiable Energy Model |
| |
Hi Lukasz,
On Fri, May 12, 2023 at 11:58 AM Lukasz Luba <lukasz.luba@arm.com> wrote: > > Hi all, > > This patch set adds a new feature which allows to modify Energy Model (EM) > power values at runtime. It will allow to better reflect power model of > a recent SoCs and silicon. Different characteristics of the power usage > can be leveraged and thus better decisions made during task placement in EAS. > > It's part of feature set know as Dynamic Energy Model. It has been presented > and discussed recently at OSPM2023 [3]. This patch set implements the 1st > improvement for the EM. > > The concepts: > 1. The CPU power usage can vary due to the workload that it's running or due > to the temperature of the SoC. The same workload can use more power when the > temperature of the silicon has increased (e.g. due to hot GPU or ISP). > In such situation or EM can be adjusted and reflect the fact of increased > power usage. That power increase is due to a factor called static power > (sometimes called simply: leakage). The CPUs in recent SoCs are different. > We have heterogeneous SoCs with 3 (or even 4) different microarchitectures. > They are also built differently with High Performance (HP) cells or > Low Power (LP) cells. They are affected by the temperature increase > differently: HP cells have bigger leakage. The SW model can leverage that > knowledge. > 2. It is also possible to change the EM to better reflect the currently > running workload. Usually the EM is derived from some average power values > taken from experiments with benchmark (e.g. Dhrystone). The model derived > from such scenario might not represent properly the workloads usually running > on the device. Therefore, runtime modification of the EM allows to switch to > a different model, when there is a need. > 3. The EM can be adjusted after boot, when all the modules are loaded and > more information about the SoC is available e.g. chip binning. This would help > to better reflect the silicon characteristics. Thus, this EM modification > API allows it now. It wasn't possible in the past and the EM had to be > 'set in stone'. > > Some design details: > The internal mechanisms for the memory allocation are handled internally in the > EM. Kernel modules can just call the new API to update the EM data and the > new memory would be provided and owned by the EM. The EM memory is used by > EAS, which impacts those design decisions. The EM writers are protected by > a mutex. This new runtime modified EM table is protected using RCU mechanism, > which fits the current EAS hot path (which already uses RCU read lock). > The unregister API handles only non-CPU (e.g. GPU, ISP) devices and uses the > same mutex as EM modifiers to make sure the memory is safely freed. > > More detailed explanation and background can be found in presentations > during LPC2022 [1][2] or in the documentation patches. > > Changelog: > v2: > - solved build warning of unused variable in patch 13/17 when EM is > not compiled in, e.g. on Intel platform for this cpufreq_cooling > - re-based on top of v6.4-rc1 > v1: > - implementation can be found here [4] > > [1] https://lpc.events/event/16/contributions/1341/attachments/955/1873/Dynamic_Energy_Model_to_handle_leakage_power.pdf > [2] https://lpc.events/event/16/contributions/1194/attachments/1114/2139/LPC2022_Energy_model_accuracy.pdf > [3] https://www.youtube.com/watch?v=2C-5uikSbtM&list=PL0fKordpLTjKsBOUcZqnzlHShri4YBL1H > [4] https://lore.kernel.org/lkml/20230314103357.26010-1-lukasz.luba@arm.com/ > > Lukasz Luba (17): > PM: EM: Refactor em_cpufreq_update_efficiencies() arguments > PM: EM: Find first CPU online while updating OPP efficiency > PM: EM: Refactor em_pd_get_efficient_state() to be more flexible > PM: EM: Create a new function em_compute_costs() > trace: energy_model: Add trace event for EM runtime modifications > PM: EM: Add update_power() callback for runtime modifications > PM: EM: Check if the get_cost() callback is present in > em_compute_costs() > PM: EM: Introduce runtime modifiable table > PM: EM: Add RCU mechanism which safely cleans the old data > PM: EM: Add runtime update interface to modify EM power > PM: EM: Use runtime modified EM for CPUs energy estimation in EAS > PM: EM: Add argument to get_cost() for runtime modification > PM: EM: Refactor struct em_perf_domain and add default_table > Documentation: EM: Add a new section about the design > Documentation: EM: Add a runtime modifiable EM design description > Documentation: EM: Add example with driver modifying the EM > Documentation: EM: Describe the API of runtime modifications
I haven't seen any responses from anyone having a vested interest in the Energy Model code.
I'm not sure what this means, but I surely can't do much about it myself without any input from the potentially interested parties.
Thanks!
| |