Re: [PATCH v2 15/17] Documentation: EM: Add a runtime modifiable EM design description

[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@xxxxxxx>
> > ---
> >   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.