Documentation: Fix typos in energy model documentation

The source of the information about the power consumed by devices can vary greatly

from one platform to another. These power costs can be estimated using

devicetree data in some cases. In others, the firmware will know better.

Alternatively, userspace might be best positioned. And so on. In order to avoid

each and every client subsystem to re-implement support for each and every

Alternatively, userspace might be best positioned. In order to avoid

having each and every client subsystem re-implement support for each and every

possible source of information on its own, the EM framework intervenes as an

abstraction layer which standardizes the format of power cost tables in the

kernel, hence enabling to avoid redundant work.

Documentation/driver-api/thermal/power_allocator.rst.

Kernel subsystems might implement automatic detection to check whether EM

registered devices have inconsistent scale (based on EM internal flag).

Important thing to keep in mind is that when the power values are expressed in

An important thing to keep in mind is that when the power values are expressed in

an 'abstract scale' deriving real energy in micro-Joules would not be possible.

The figure below depicts an example of drivers (Arm-specific here, but the

should call EM API to free it safely when it's no longer needed. The EM

framework will handle the clean-up when it's possible.

The kernel code which want to modify the EM values is protected from concurrent

The kernel code which wants to modify the EM values is protected from concurrent

access using a mutex. Therefore, the device driver code must run in sleeping

context when it tries to modify the EM.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 'advanced' EM gets its name due to the fact that the driver is allowed

to provide more precised power model. It's not limited to some implemented math

to provide a more precise power model. It's not limited to some implemented math

formula in the framework (like it is in 'simple' EM case). It can better reflect

the real power measurements performed for each performance state. Thus, this

registration method should be preferred in case considering EM static power

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 'simple' EM is registered using the framework helper function

cpufreq_register_em_with_opp(). It implements a power model which is tight to

cpufreq_register_em_with_opp(). It implements a power model which is tied to a

math formula::

	Power = C * V^2 * f

states in ascending order.

This function must be called in the RCU read lock section (after the

rcu_read_lock()). When the EM table is not needed anymore there is a need to

call rcu_real_unlock(). In this way the EM safely uses the RCU read section

call rcu_read_unlock(). In this way the EM safely uses the RCU read section

and protects the users. It also allows the EM framework to manage the memory

and free it. More details how to use it can be found in Section 3.2 in the

example driver.

    From these calculations, the Case 1 has the lowest total energy. So CPU 1

    is be the best candidate from an energy-efficiency standpoint.

    is the best candidate from an energy-efficiency standpoint.

Big CPUs are generally more power hungry than the little ones and are thus used

mainly when a task doesn't fit the littles. However, little CPUs aren't always

of the little CPUs can be less energy-efficient than the lowest OPPs of the

bigs, for example. So, if the little CPUs happen to have enough utilization at

a specific point in time, a small task waking up at that moment could be better

of executing on the big side in order to save energy, even though it would fit

off executing on the big side in order to save energy, even though it would fit

on the little side.

And even in the case where all OPPs of the big CPUs are less energy-efficient

throughput. In order to avoid hurting performance with EAS, CPUs are flagged as

'over-utilized' as soon as they are used at more than 80% of their compute

capacity. As long as no CPUs are over-utilized in a root domain, load balancing

is disabled and EAS overridess the wake-up balancing code. EAS is likely to load

is disabled and EAS overrides the wake-up balancing code. EAS is likely to load

the most energy efficient CPUs of the system more than the others if that can be

done without harming throughput. So, the load-balancer is disabled to prevent

it from breaking the energy-efficient task placement found by EAS. It is safe to

6.5 Scale-invariant utilization signals

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In order to make accurate prediction across CPUs and for all performance

In order to make accurate predictions across CPUs and for all performance

states, EAS needs frequency-invariant and CPU-invariant PELT signals. These can

be obtained using the architecture-defined arch_scale{cpu,freq}_capacity()

callbacks.