Messages in this thread | | | Date | Mon, 3 Jul 2023 17:13:31 +0100 | Subject | Re: [PATCH v2 15/17] Documentation: EM: Add a runtime modifiable EM design description | From | Lukasz Luba <> |
| |
On 5/30/23 11:42, Dietmar Eggemann wrote: > On 12/05/2023 11:57, Lukasz Luba wrote: >> Document the new runtime modifiable EM design and how it can be used. >> Change the last section layout and allow to provide another example >> how to use this new API in a driver code. >> >> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> >> --- >> Documentation/power/energy-model.rst | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst >> index e97c7f18d8bd..64c2462dc9a6 100644 >> --- a/Documentation/power/energy-model.rst >> +++ b/Documentation/power/energy-model.rst >> @@ -89,6 +89,26 @@ due to the workload instruction mix and data set is not modeled. >> Also static power which can change during runtime due to variation of SOC >> temperature is not modeled in EM. >> >> +2.2 Runtime modifiable EM >> +^^^^^^^^^^^^^^^^^^^^^^^^^ >> + >> +To better reflect power variation due to static power (leakage) the EM >> +supports runtime modifications of the power values. The mechanism relies on >> +RCU to free the modifiable EM perf_state table memory. Its user, the task >> +scheduler, also uses RCU to access this memory. The EM framework is >> +responsible for allocating the new memory for the modifiable EM perf_state >> +table. The old memory is freed automatically using RCU callback mechanism. >> +This design decision is made based on task scheduler using that data and >> +to prevent wrong usage of kernel modules if they would be responsible for the >> +memory management. >> +The drivers which want to modify the EM values are protected from concurrent >> +access using a mutex. Therefore, the drivers must use sleeping context when >> +they want to modify the EM. The runtime modifiable EM might also be used for >> +better reflecting real workload scenarios, e.g. when they pop-up on the screen >> +and will run for longer period, such as: games, video recoding or playing, >> +video calls, etc. It is up to the platform engineers to experiment and choose >> +the right approach for their device. > > IMHO, there are a lot of design aspects missing here. > > E.g. > > Why 2 tables, modifiable (a) and default (b)? > > Why does only EAS use (a)? > > (a) and (b) being the same performance state table until first call to > modify (a) () >
I'll add that explanation in the v3. I wanted to avoid such detailed description about e.g. 'being the same performance state table until first call to > modify (a)' since it's a memory optimization bit. Although, I will add that reason to the doc as well.
| |