Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux
Pull thermal management updates from Zhang Rui:
"Highlights:
- introduction of Dove thermal sensor driver.
- introduction of Kirkwood thermal sensor driver.
- introduction of intel_powerclamp thermal cooling device driver.
- add interrupt and DT support for rcar thermal driver.
- add thermal emulation support which allows platform thermal driver
to do software/hardware emulation for thermal issues."
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (36 commits)
thermal: rcar: remove __devinitconst
thermal: return an error on failure to register thermal class
Thermal: rename thermal governor Kconfig option to avoid generic naming
thermal: exynos: Use the new thermal trend type for quick cooling action.
Thermal: exynos: Add support for temperature falling interrupt.
Thermal: Dove: Add Themal sensor support for Dove.
thermal: Add support for the thermal sensor on Kirkwood SoCs
thermal: rcar: add Device Tree support
thermal: rcar: remove machine_power_off() from rcar_thermal_notify()
thermal: rcar: add interrupt support
thermal: rcar: add read/write functions for common/priv data
thermal: rcar: multi channel support
thermal: rcar: use mutex lock instead of spin lock
thermal: rcar: enable CPCTL to use hardware TSC deciding
thermal: rcar: use parenthesis on macro
Thermal: fix a build warning when CONFIG_THERMAL_EMULATION cleared
Thermal: fix a wrong comment
thermal: sysfs: Add a new sysfs node emul_temp for thermal emulation
PM: intel_powerclamp: off by one in start_power_clamp()
thermal: exynos: Miscellaneous fixes to support falling threshold interrupt
...
Cette révision appartient à :
Linus Torvalds
53
Documentation/thermal/exynos_thermal_emulation
Fichier normal
53
Documentation/thermal/exynos_thermal_emulation
Fichier normal
@@ -0,0 +1,53 @@
|
||||
EXYNOS EMULATION MODE
|
||||
========================
|
||||
|
||||
Copyright (C) 2012 Samsung Electronics
|
||||
|
||||
Written by Jonghwa Lee <jonghwa3.lee@samsung.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal management unit.
|
||||
Thermal emulation mode supports software debug for TMU's operation. User can set temperature
|
||||
manually with software code and TMU will read current temperature from user value not from
|
||||
sensor's value.
|
||||
|
||||
Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in available.
|
||||
When it's enabled, sysfs node will be created under
|
||||
/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
|
||||
|
||||
The sysfs node, 'emulation', will contain value 0 for the initial state. When you input any
|
||||
temperature you want to update to sysfs node, it automatically enable emulation mode and
|
||||
current temperature will be changed into it.
|
||||
(Exynos also supports user changable delay time which would be used to delay of
|
||||
changing temperature. However, this node only uses same delay of real sensing time, 938us.)
|
||||
|
||||
Exynos emulation mode requires synchronous of value changing and enabling. It means when you
|
||||
want to update the any value of delay or next temperature, then you have to enable emulation
|
||||
mode at the same time. (Or you have to keep the mode enabling.) If you don't, it fails to
|
||||
change the value to updated one and just use last succeessful value repeatedly. That's why
|
||||
this node gives users the right to change termerpature only. Just one interface makes it more
|
||||
simply to use.
|
||||
|
||||
Disabling emulation mode only requires writing value 0 to sysfs node.
|
||||
|
||||
|
||||
TEMP 120 |
|
||||
|
|
||||
100 |
|
||||
|
|
||||
80 |
|
||||
| +-----------
|
||||
60 | | |
|
||||
| +-------------| |
|
||||
40 | | | |
|
||||
| | | |
|
||||
20 | | | +----------
|
||||
| | | | |
|
||||
0 |______________|_____________|__________|__________|_________
|
||||
A A A A TIME
|
||||
|<----->| |<----->| |<----->| |
|
||||
| 938us | | | | | |
|
||||
emulation : 0 50 | 70 | 20 | 0
|
||||
current temp : sensor 50 70 20 sensor
|
||||
307
Documentation/thermal/intel_powerclamp.txt
Fichier normal
307
Documentation/thermal/intel_powerclamp.txt
Fichier normal
@@ -0,0 +1,307 @@
|
||||
=======================
|
||||
INTEL POWERCLAMP DRIVER
|
||||
=======================
|
||||
By: Arjan van de Ven <arjan@linux.intel.com>
|
||||
Jacob Pan <jacob.jun.pan@linux.intel.com>
|
||||
|
||||
Contents:
|
||||
(*) Introduction
|
||||
- Goals and Objectives
|
||||
|
||||
(*) Theory of Operation
|
||||
- Idle Injection
|
||||
- Calibration
|
||||
|
||||
(*) Performance Analysis
|
||||
- Effectiveness and Limitations
|
||||
- Power vs Performance
|
||||
- Scalability
|
||||
- Calibration
|
||||
- Comparison with Alternative Techniques
|
||||
|
||||
(*) Usage and Interfaces
|
||||
- Generic Thermal Layer (sysfs)
|
||||
- Kernel APIs (TBD)
|
||||
|
||||
============
|
||||
INTRODUCTION
|
||||
============
|
||||
|
||||
Consider the situation where a system’s power consumption must be
|
||||
reduced at runtime, due to power budget, thermal constraint, or noise
|
||||
level, and where active cooling is not preferred. Software managed
|
||||
passive power reduction must be performed to prevent the hardware
|
||||
actions that are designed for catastrophic scenarios.
|
||||
|
||||
Currently, P-states, T-states (clock modulation), and CPU offlining
|
||||
are used for CPU throttling.
|
||||
|
||||
On Intel CPUs, C-states provide effective power reduction, but so far
|
||||
they’re only used opportunistically, based on workload. With the
|
||||
development of intel_powerclamp driver, the method of synchronizing
|
||||
idle injection across all online CPU threads was introduced. The goal
|
||||
is to achieve forced and controllable C-state residency.
|
||||
|
||||
Test/Analysis has been made in the areas of power, performance,
|
||||
scalability, and user experience. In many cases, clear advantage is
|
||||
shown over taking the CPU offline or modulating the CPU clock.
|
||||
|
||||
|
||||
===================
|
||||
THEORY OF OPERATION
|
||||
===================
|
||||
|
||||
Idle Injection
|
||||
--------------
|
||||
|
||||
On modern Intel processors (Nehalem or later), package level C-state
|
||||
residency is available in MSRs, thus also available to the kernel.
|
||||
|
||||
These MSRs are:
|
||||
#define MSR_PKG_C2_RESIDENCY 0x60D
|
||||
#define MSR_PKG_C3_RESIDENCY 0x3F8
|
||||
#define MSR_PKG_C6_RESIDENCY 0x3F9
|
||||
#define MSR_PKG_C7_RESIDENCY 0x3FA
|
||||
|
||||
If the kernel can also inject idle time to the system, then a
|
||||
closed-loop control system can be established that manages package
|
||||
level C-state. The intel_powerclamp driver is conceived as such a
|
||||
control system, where the target set point is a user-selected idle
|
||||
ratio (based on power reduction), and the error is the difference
|
||||
between the actual package level C-state residency ratio and the target idle
|
||||
ratio.
|
||||
|
||||
Injection is controlled by high priority kernel threads, spawned for
|
||||
each online CPU.
|
||||
|
||||
These kernel threads, with SCHED_FIFO class, are created to perform
|
||||
clamping actions of controlled duty ratio and duration. Each per-CPU
|
||||
thread synchronizes its idle time and duration, based on the rounding
|
||||
of jiffies, so accumulated errors can be prevented to avoid a jittery
|
||||
effect. Threads are also bound to the CPU such that they cannot be
|
||||
migrated, unless the CPU is taken offline. In this case, threads
|
||||
belong to the offlined CPUs will be terminated immediately.
|
||||
|
||||
Running as SCHED_FIFO and relatively high priority, also allows such
|
||||
scheme to work for both preemptable and non-preemptable kernels.
|
||||
Alignment of idle time around jiffies ensures scalability for HZ
|
||||
values. This effect can be better visualized using a Perf timechart.
|
||||
The following diagram shows the behavior of kernel thread
|
||||
kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
|
||||
for a given "duration", then relinquishes the CPU to other tasks,
|
||||
until the next time interval.
|
||||
|
||||
The NOHZ schedule tick is disabled during idle time, but interrupts
|
||||
are not masked. Tests show that the extra wakeups from scheduler tick
|
||||
have a dramatic impact on the effectiveness of the powerclamp driver
|
||||
on large scale systems (Westmere system with 80 processors).
|
||||
|
||||
CPU0
|
||||
____________ ____________
|
||||
kidle_inject/0 | sleep | mwait | sleep |
|
||||
_________| |________| |_______
|
||||
duration
|
||||
CPU1
|
||||
____________ ____________
|
||||
kidle_inject/1 | sleep | mwait | sleep |
|
||||
_________| |________| |_______
|
||||
^
|
||||
|
|
||||
|
|
||||
roundup(jiffies, interval)
|
||||
|
||||
Only one CPU is allowed to collect statistics and update global
|
||||
control parameters. This CPU is referred to as the controlling CPU in
|
||||
this document. The controlling CPU is elected at runtime, with a
|
||||
policy that favors BSP, taking into account the possibility of a CPU
|
||||
hot-plug.
|
||||
|
||||
In terms of dynamics of the idle control system, package level idle
|
||||
time is considered largely as a non-causal system where its behavior
|
||||
cannot be based on the past or current input. Therefore, the
|
||||
intel_powerclamp driver attempts to enforce the desired idle time
|
||||
instantly as given input (target idle ratio). After injection,
|
||||
powerclamp moniors the actual idle for a given time window and adjust
|
||||
the next injection accordingly to avoid over/under correction.
|
||||
|
||||
When used in a causal control system, such as a temperature control,
|
||||
it is up to the user of this driver to implement algorithms where
|
||||
past samples and outputs are included in the feedback. For example, a
|
||||
PID-based thermal controller can use the powerclamp driver to
|
||||
maintain a desired target temperature, based on integral and
|
||||
derivative gains of the past samples.
|
||||
|
||||
|
||||
|
||||
Calibration
|
||||
-----------
|
||||
During scalability testing, it is observed that synchronized actions
|
||||
among CPUs become challenging as the number of cores grows. This is
|
||||
also true for the ability of a system to enter package level C-states.
|
||||
|
||||
To make sure the intel_powerclamp driver scales well, online
|
||||
calibration is implemented. The goals for doing such a calibration
|
||||
are:
|
||||
|
||||
a) determine the effective range of idle injection ratio
|
||||
b) determine the amount of compensation needed at each target ratio
|
||||
|
||||
Compensation to each target ratio consists of two parts:
|
||||
|
||||
a) steady state error compensation
|
||||
This is to offset the error occurring when the system can
|
||||
enter idle without extra wakeups (such as external interrupts).
|
||||
|
||||
b) dynamic error compensation
|
||||
When an excessive amount of wakeups occurs during idle, an
|
||||
additional idle ratio can be added to quiet interrupts, by
|
||||
slowing down CPU activities.
|
||||
|
||||
A debugfs file is provided for the user to examine compensation
|
||||
progress and results, such as on a Westmere system.
|
||||
[jacob@nex01 ~]$ cat
|
||||
/sys/kernel/debug/intel_powerclamp/powerclamp_calib
|
||||
controlling cpu: 0
|
||||
pct confidence steady dynamic (compensation)
|
||||
0 0 0 0
|
||||
1 1 0 0
|
||||
2 1 1 0
|
||||
3 3 1 0
|
||||
4 3 1 0
|
||||
5 3 1 0
|
||||
6 3 1 0
|
||||
7 3 1 0
|
||||
8 3 1 0
|
||||
...
|
||||
30 3 2 0
|
||||
31 3 2 0
|
||||
32 3 1 0
|
||||
33 3 2 0
|
||||
34 3 1 0
|
||||
35 3 2 0
|
||||
36 3 1 0
|
||||
37 3 2 0
|
||||
38 3 1 0
|
||||
39 3 2 0
|
||||
40 3 3 0
|
||||
41 3 1 0
|
||||
42 3 2 0
|
||||
43 3 1 0
|
||||
44 3 1 0
|
||||
45 3 2 0
|
||||
46 3 3 0
|
||||
47 3 0 0
|
||||
48 3 2 0
|
||||
49 3 3 0
|
||||
|
||||
Calibration occurs during runtime. No offline method is available.
|
||||
Steady state compensation is used only when confidence levels of all
|
||||
adjacent ratios have reached satisfactory level. A confidence level
|
||||
is accumulated based on clean data collected at runtime. Data
|
||||
collected during a period without extra interrupts is considered
|
||||
clean.
|
||||
|
||||
To compensate for excessive amounts of wakeup during idle, additional
|
||||
idle time is injected when such a condition is detected. Currently,
|
||||
we have a simple algorithm to double the injection ratio. A possible
|
||||
enhancement might be to throttle the offending IRQ, such as delaying
|
||||
EOI for level triggered interrupts. But it is a challenge to be
|
||||
non-intrusive to the scheduler or the IRQ core code.
|
||||
|
||||
|
||||
CPU Online/Offline
|
||||
------------------
|
||||
Per-CPU kernel threads are started/stopped upon receiving
|
||||
notifications of CPU hotplug activities. The intel_powerclamp driver
|
||||
keeps track of clamping kernel threads, even after they are migrated
|
||||
to other CPUs, after a CPU offline event.
|
||||
|
||||
|
||||
=====================
|
||||
Performance Analysis
|
||||
=====================
|
||||
This section describes the general performance data collected on
|
||||
multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
|
||||
|
||||
Effectiveness and Limitations
|
||||
-----------------------------
|
||||
The maximum range that idle injection is allowed is capped at 50
|
||||
percent. As mentioned earlier, since interrupts are allowed during
|
||||
forced idle time, excessive interrupts could result in less
|
||||
effectiveness. The extreme case would be doing a ping -f to generated
|
||||
flooded network interrupts without much CPU acknowledgement. In this
|
||||
case, little can be done from the idle injection threads. In most
|
||||
normal cases, such as scp a large file, applications can be throttled
|
||||
by the powerclamp driver, since slowing down the CPU also slows down
|
||||
network protocol processing, which in turn reduces interrupts.
|
||||
|
||||
When control parameters change at runtime by the controlling CPU, it
|
||||
may take an additional period for the rest of the CPUs to catch up
|
||||
with the changes. During this time, idle injection is out of sync,
|
||||
thus not able to enter package C- states at the expected ratio. But
|
||||
this effect is minor, in that in most cases change to the target
|
||||
ratio is updated much less frequently than the idle injection
|
||||
frequency.
|
||||
|
||||
Scalability
|
||||
-----------
|
||||
Tests also show a minor, but measurable, difference between the 4P/8P
|
||||
Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
|
||||
More compensation is needed on Westmere for the same amount of
|
||||
target idle ratio. The compensation also increases as the idle ratio
|
||||
gets larger. The above reason constitutes the need for the
|
||||
calibration code.
|
||||
|
||||
On the IVB 8P system, compared to an offline CPU, powerclamp can
|
||||
achieve up to 40% better performance per watt. (measured by a spin
|
||||
counter summed over per CPU counting threads spawned for all running
|
||||
CPUs).
|
||||
|
||||
====================
|
||||
Usage and Interfaces
|
||||
====================
|
||||
The powerclamp driver is registered to the generic thermal layer as a
|
||||
cooling device. Currently, it’s not bound to any thermal zones.
|
||||
|
||||
jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
|
||||
cur_state:0
|
||||
max_state:50
|
||||
type:intel_powerclamp
|
||||
|
||||
Example usage:
|
||||
- To inject 25% idle time
|
||||
$ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
|
||||
"
|
||||
|
||||
If the system is not busy and has more than 25% idle time already,
|
||||
then the powerclamp driver will not start idle injection. Using Top
|
||||
will not show idle injection kernel threads.
|
||||
|
||||
If the system is busy (spin test below) and has less than 25% natural
|
||||
idle time, powerclamp kernel threads will do idle injection, which
|
||||
appear running to the scheduler. But the overall system idle is still
|
||||
reflected. In this example, 24.1% idle is shown. This helps the
|
||||
system admin or user determine the cause of slowdown, when a
|
||||
powerclamp driver is in action.
|
||||
|
||||
|
||||
Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
|
||||
Cpu(s): 71.2%us, 4.7%sy, 0.0%ni, 24.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
|
||||
Mem: 3943228k total, 1689632k used, 2253596k free, 74960k buffers
|
||||
Swap: 4087804k total, 0k used, 4087804k free, 945336k cached
|
||||
|
||||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||||
3352 jacob 20 0 262m 644 428 S 286 0.0 0:17.16 spin
|
||||
3341 root -51 0 0 0 0 D 25 0.0 0:01.62 kidle_inject/0
|
||||
3344 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/3
|
||||
3342 root -51 0 0 0 0 D 25 0.0 0:01.61 kidle_inject/1
|
||||
3343 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/2
|
||||
2935 jacob 20 0 696m 125m 35m S 5 3.3 0:31.11 firefox
|
||||
1546 root 20 0 158m 20m 6640 S 3 0.5 0:26.97 Xorg
|
||||
2100 jacob 20 0 1223m 88m 30m S 3 2.3 0:23.68 compiz
|
||||
|
||||
Tests have shown that by using the powerclamp driver as a cooling
|
||||
device, a PID based userspace thermal controller can manage to
|
||||
control CPU temperature effectively, when no other thermal influence
|
||||
is added. For example, a UltraBook user can compile the kernel under
|
||||
certain temperature (below most active trip points).
|
||||
@@ -55,6 +55,8 @@ temperature) and throttle appropriate devices.
|
||||
.get_trip_type: get the type of certain trip point.
|
||||
.get_trip_temp: get the temperature above which the certain trip point
|
||||
will be fired.
|
||||
.set_emul_temp: set the emulation temperature which helps in debugging
|
||||
different threshold temperature points.
|
||||
|
||||
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
|
||||
|
||||
@@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered:
|
||||
|---trip_point_[0-*]_temp: Trip point temperature
|
||||
|---trip_point_[0-*]_type: Trip point type
|
||||
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
|
||||
|---emul_temp: Emulated temperature set node
|
||||
|
||||
Thermal cooling device sys I/F, created once it's registered:
|
||||
/sys/class/thermal/cooling_device[0-*]:
|
||||
@@ -252,6 +255,16 @@ passive
|
||||
Valid values: 0 (disabled) or greater than 1000
|
||||
RW, Optional
|
||||
|
||||
emul_temp
|
||||
Interface to set the emulated temperature method in thermal zone
|
||||
(sensor). After setting this temperature, the thermal zone may pass
|
||||
this temperature to platform emulation function if registered or
|
||||
cache it locally. This is useful in debugging different temperature
|
||||
threshold and its associated cooling action. This is write only node
|
||||
and writing 0 on this node should disable emulation.
|
||||
Unit: millidegree Celsius
|
||||
WO, Optional
|
||||
|
||||
*****************************
|
||||
* Cooling device attributes *
|
||||
*****************************
|
||||
@@ -329,8 +342,9 @@ The framework includes a simple notification mechanism, in the form of a
|
||||
netlink event. Netlink socket initialization is done during the _init_
|
||||
of the framework. Drivers which intend to use the notification mechanism
|
||||
just need to call thermal_generate_netlink_event() with two arguments viz
|
||||
(originator, event). Typically the originator will be an integer assigned
|
||||
to a thermal_zone_device when it registers itself with the framework. The
|
||||
(originator, event). The originator is a pointer to struct thermal_zone_device
|
||||
from where the event has been originated. An integer which represents the
|
||||
thermal zone device will be used in the message to identify the zone. The
|
||||
event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL,
|
||||
THERMAL_DEV_FAULT}. Notification can be sent when the current temperature
|
||||
crosses any of the configured thresholds.
|
||||
|
||||
Référencer dans un nouveau ticket
Bloquer un utilisateur