| Message ID | 20230512095743.3393563-16-lukasz.luba@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Introduce runtime modifiable Energy Model | expand |
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) () > + > > 3. Core APIs > ------------
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.
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. + 3. Core APIs ------------
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(+)