lkml.org 
[lkml]   [2023]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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!

    \
     
     \ /
      Last update: 2023-05-24 19:26    [W:4.461 / U:1.360 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site