PM: EM: Clarify abstract scale usage for power values in Energy Model
The Energy Model (EM) can store power values in milli-Watts or in abstract scale. This might cause issues in the subsystems which use the EM for estimating the device power, such as: - mixing of different scales in a subsystem which uses multiple (cooling) devices (e.g. thermal Intelligent Power Allocation (IPA)) - assuming that energy [milli-Joules] can be derived from the EM power values which might not be possible since the power scale doesn't have to be in milli-Watts To avoid misconfiguration add the requisite documentation to the EM and related subsystems: EAS and IPA. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This commit is contained in:
parent
c250d50fe2
commit
5a64f77569
Documentation
|
@ -71,7 +71,9 @@ to the speed-grade of the silicon. `sustainable_power` is therefore
|
||||||
simply an estimate, and may be tuned to affect the aggressiveness of
|
simply an estimate, and may be tuned to affect the aggressiveness of
|
||||||
the thermal ramp. For reference, the sustainable power of a 4" phone
|
the thermal ramp. For reference, the sustainable power of a 4" phone
|
||||||
is typically 2000mW, while on a 10" tablet is around 4500mW (may vary
|
is typically 2000mW, while on a 10" tablet is around 4500mW (may vary
|
||||||
depending on screen size).
|
depending on screen size). It is possible to have the power value
|
||||||
|
expressed in an abstract scale. The sustained power should be aligned
|
||||||
|
to the scale used by the related cooling devices.
|
||||||
|
|
||||||
If you are using device tree, do add it as a property of the
|
If you are using device tree, do add it as a property of the
|
||||||
thermal-zone. For example::
|
thermal-zone. For example::
|
||||||
|
@ -269,3 +271,11 @@ won't be very good. Note that this is not particular to this
|
||||||
governor, step-wise will also misbehave if you call its throttle()
|
governor, step-wise will also misbehave if you call its throttle()
|
||||||
faster than the normal thermal framework tick (due to interrupts for
|
faster than the normal thermal framework tick (due to interrupts for
|
||||||
example) as it will overreact.
|
example) as it will overreact.
|
||||||
|
|
||||||
|
Energy Model requirements
|
||||||
|
=========================
|
||||||
|
|
||||||
|
Another important thing is the consistent scale of the power values
|
||||||
|
provided by the cooling devices. All of the cooling devices in a single
|
||||||
|
thermal zone should have power values reported either in milli-Watts
|
||||||
|
or scaled to the same 'abstract scale'.
|
||||||
|
|
|
@ -20,6 +20,19 @@ 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
|
abstraction layer which standardizes the format of power cost tables in the
|
||||||
kernel, hence enabling to avoid redundant work.
|
kernel, hence enabling to avoid redundant work.
|
||||||
|
|
||||||
|
The power values might be expressed in milli-Watts or in an 'abstract scale'.
|
||||||
|
Multiple subsystems might use the EM and it is up to the system integrator to
|
||||||
|
check that the requirements for the power value scale types are met. An example
|
||||||
|
can be found in the Energy-Aware Scheduler documentation
|
||||||
|
Documentation/scheduler/sched-energy.rst. For some subsystems like thermal or
|
||||||
|
powercap power values expressed in an 'abstract scale' might cause issues.
|
||||||
|
These subsystems are more interested in estimation of power used in the past,
|
||||||
|
thus the real milli-Watts might be needed. An example of these requirements can
|
||||||
|
be found in the Intelligent Power Allocation in
|
||||||
|
Documentation/driver-api/thermal/power_allocator.rst.
|
||||||
|
Important thing to keep in mind is that when the power values are expressed in
|
||||||
|
an 'abstract scale' deriving real energy in milli-Joules would not be possible.
|
||||||
|
|
||||||
The figure below depicts an example of drivers (Arm-specific here, but the
|
The figure below depicts an example of drivers (Arm-specific here, but the
|
||||||
approach is applicable to any architecture) providing power costs to the EM
|
approach is applicable to any architecture) providing power costs to the EM
|
||||||
framework, and interested clients reading the data from it::
|
framework, and interested clients reading the data from it::
|
||||||
|
|
|
@ -350,6 +350,11 @@ independent EM framework in Documentation/power/energy-model.rst.
|
||||||
Please also note that the scheduling domains need to be re-built after the
|
Please also note that the scheduling domains need to be re-built after the
|
||||||
EM has been registered in order to start EAS.
|
EM has been registered in order to start EAS.
|
||||||
|
|
||||||
|
EAS uses the EM to make a forecasting decision on energy usage and thus it is
|
||||||
|
more focused on the difference when checking possible options for task
|
||||||
|
placement. For EAS it doesn't matter whether the EM power values are expressed
|
||||||
|
in milli-Watts or in an 'abstract scale'.
|
||||||
|
|
||||||
|
|
||||||
6.3 - Energy Model complexity
|
6.3 - Energy Model complexity
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
Loading…
Reference in New Issue