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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2023 12:42:19 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org, rafael@...nel.org
Cc:     rui.zhang@...el.com, amit.kucheria@...durent.com,
        amit.kachhap@...il.com, daniel.lezcano@...aro.org,
        viresh.kumar@...aro.org, len.brown@...el.com, pavel@....cz,
        Pierre.Gondois@....com, ionela.voinescu@....com,
        rostedt@...dmis.org, mhiramat@...nel.org
Subject: Re: [PATCH v2 15/17] Documentation: EM: Add a runtime modifiable EM
 design description

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