lineage-20.0
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Abhijeet Dharmapurikar
|
c208338efc |
power: em: correct increasing freq/power ratio
As freq increases freq/power should decrease, indicating nonlinearly higher power is required for running at higher frequencies. If freq/power increases, the cost associated with that freq will be lower than its previous one, causing the energy calculations to choose a cpu with that frequency over a cpu with the previous lesser freq. For some frequencies, if their voltage increment from the previous ones is very small (or is the same), we could end up with higher freq/power ratio. This is primarily because of_dev_pm_opp_get_cpu_power() returns power in mW and looses precision. But instead of addressing it, enforce the same cost as the previous frequency. The energy evaluation code prefers the previous cpu when the energy costs are same as other candidates. By keeping the energy costs same in these situations we are increasing the likely hood of selecting prev cpu even if it results in a slight freq bump. In general, selecting prev cpu is beneficial because it avoids warming up the caches at a different cpu. Change-Id: Ic66ab18ba65f2917b73d9fbe92a39b743b9839a0 Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org> |
||
Quentin Perret
|
5f5a57750b |
FROMGIT: PM / EM: Expose the Energy Model in debugfs
The recently introduced Energy Model (EM) framework manages power cost
tables of CPUs. These tables are currently only visible from kernel
space. However, in order to debug the behaviour of subsystems that use
the EM (EAS for example), it is often required to know what the power
costs are from userspace.
For this reason, introduce under /sys/kernel/debug/energy_model a set of
directories representing the performance domains of the system. Each
performance domain contains a set of sub-directories representing the
different capacity states (cs) and their attributes, as well as a file
exposing the related CPUs.
The resulting hierarchy is as follows on Arm juno r0 for example:
/sys/kernel/debug/energy_model
├── pd0
│ ├── cpus
│ ├── cs:450000
│ │ ├── cost
│ │ ├── frequency
│ │ └── power
│ ├── cs:575000
│ │ ├── cost
│ │ ├── frequency
│ │ └── power
│ ├── cs:700000
│ │ ├── cost
│ │ ├── frequency
│ │ └── power
│ ├── cs:775000
│ │ ├── cost
│ │ ├── frequency
│ │ └── power
│ └── cs:850000
│ ├── cost
│ ├── frequency
│ └── power
└── pd1
├── cpus
├── cs:1100000
│ ├── cost
│ ├── frequency
│ └── power
├── cs:450000
│ ├── cost
│ ├── frequency
│ └── power
├── cs:625000
│ ├── cost
│ ├── frequency
│ └── power
├── cs:800000
│ ├── cost
│ ├── frequency
│ └── power
└── cs:950000
├── cost
├── frequency
└── power
Bug: 120440300
Change-Id: I4098c3d3e07fc4a14514751ac881422131b759e9
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9cac42d0645ceb2ca8b815cee04810ec9b0d13b3
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge)
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
|
||
|
Quentin Perret
|
9f5e702922 |
Revert "FROMLIST: PM / EM: Expose the Energy Model in sysfs"
This reverts commit
|
||
|
Quentin Perret
|
b8c80a0f42 |
FROMLIST: PM / EM: Expose the Energy Model in sysfs
Expose the Energy Model (read-only) of all performance domains in sysfs
for convenience. To do so, add a kobject to the CPU subsystem under the
umbrella of which a kobject for each performance domain is attached.
The resulting hierarchy is as follows for a platform with two
performance domains for example:
/sys/devices/system/cpu/energy_model
├── pd0
│ ├── cost
│ ├── cpus
│ ├── frequency
│ └── power
└── pd4
├── cost
├── cpus
├── frequency
└── power
In this implementation, the kobject abstraction is only used as a
convenient way of exposing data to sysfs. However, it could also be
used in the future to allocate and release performance domains in a more
dynamic way using reference counting.
Change-Id: Ia98bcae21c3578e385be9c6b030c9adff8210909
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Message-Id: <20181016101513.26919-5-quentin.perret@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
|
||
|
Quentin Perret
|
9cbf2b68ca |
FROMLIST: PM: Introduce an Energy Model management framework
Several subsystems in the kernel (task scheduler and/or thermal at the
time of writing) can benefit from knowing about the energy consumed by
CPUs. Yet, this information can come from different sources (DT or
firmware for example), in different formats, hence making it hard to
exploit without a standard API.
As an attempt to address this, introduce a centralized Energy Model
(EM) management framework which aggregates the power values provided
by drivers into a table for each performance domain in the system. The
power cost tables are made available to interested clients (e.g. task
scheduler or thermal) via platform-agnostic APIs. The overall design
is represented by the diagram below (focused on Arm-related drivers as
an example, but applicable to any architecture):
+---------------+ +-----------------+ +-------------+
| Thermal (IPA) | | Scheduler (EAS) | | Other |
+---------------+ +-----------------+ +-------------+
| | em_pd_energy() |
| | em_cpu_get() |
+-----------+ | +--------+
| | |
v v v
+---------------------+
| |
| Energy Model |
| |
| Framework |
| |
+---------------------+
^ ^ ^
| | | em_register_perf_domain()
+----------+ | +---------+
| | |
+---------------+ +---------------+ +--------------+
| cpufreq-dt | | arm_scmi | | Other |
+---------------+ +---------------+ +--------------+
^ ^ ^
| | |
+--------------+ +---------------+ +--------------+
| Device Tree | | Firmware | | ? |
+--------------+ +---------------+ +--------------+
Drivers (typically, but not limited to, CPUFreq drivers) can register
data in the EM framework using the em_register_perf_domain() API. The
calling driver must provide a callback function with a standardized
signature that will be used by the EM framework to build the power
cost tables of the performance domain. This design should offer a lot of
flexibility to calling drivers which are free of reading information
from any location and to use any technique to compute power costs.
Moreover, the capacity states registered by drivers in the EM framework
are not required to match real performance states of the target. This
is particularly important on targets where the performance states are
not known by the OS.
The power cost coefficients managed by the EM framework are specified in
milli-watts. Although the two potential users of those coefficients (IPA
and EAS) only need relative correctness, IPA specifically needs to
compare the power of CPUs with the power of other components (GPUs, for
example), which are still expressed in absolute terms in their
respective subsystems. Hence, specifying the power of CPUs in
milli-watts should help transitioning IPA to using the EM framework
without introducing new problems by keeping units comparable across
sub-systems.
On the longer term, the EM of other devices than CPUs could also be
managed by the EM framework, which would enable to remove the absolute
unit. However, this is not absolutely required as a first step, so this
extension of the EM framework is left for later.
On the client side, the EM framework offers APIs to access the power
cost tables of a CPU (em_cpu_get()), and to estimate the energy
consumed by the CPUs of a performance domain (em_pd_energy()). Clients
such as the task scheduler can then use these APIs to access the shared
data structures holding the Energy Model of CPUs.
Change-Id: I384cb3d28f37fe82c2943d7208a4cf5dcca2b6bd
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Message-Id: <20181016101513.26919-4-quentin.perret@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
|