Description
The Power Management and Thermal Control micro-conference is about all things related to saving energy and managing heat. Among other things, we care about CPU, platform and device power-management mechanisms, thermal control support, and power capping. In particular, we are interested in improving and extending thermal control support in the Linux kernel and utilizing energy-saving features of modern hardware.
The general goal is to facilitate cross-framework and cross-platform discussions in order to improve energy-awareness and thermal control in Linux.
Since the previous iteration of this micro-conference, several topics covered by it have been addressed or work is in progress to address them, including:
- Thermal zones suspend and resume relocation closer to device suspend and resume, respectively: https://lore.kernel.org/linux-pm/12871778.O9o76ZdvQC@rafael.j.wysocki/
- Step-wise thermal governor improvements: https://lore.kernel.org/linux-pm/12745610.O9o76ZdvQC@rafael.j.wysocki/
- Support for latency limits in system-wide power management idle states: https://lore.kernel.org/linux-pm/20260205-topic-lpm-pmdomain-device-constraints-v2-0-61f7be7d35ac@baylibre.com/
- Support for fine-grained sync_state in generic PM domains: https://lore.kernel.org/linux-pm/20260410104058.83748-1-ulf.hansson@linaro.org/
- Support for remote processor cooling: https://lore.kernel.org/linux-pm/20260127155722.2797783-1-gaurav.kohli@oss.qualcomm.com/ and https://lore.kernel.org/linux-pm/20260419182203.4083985-1-daniel.lezcano@oss.qualcomm.com/
The topics that we would like to cover this year include, but are not limited to:
- Support for sync_state in more subsystems beyond generic PM domains
- Remaining rough edges in kernel thermal control support
- Cooling devices and thermal zones with parents
- thermald improvements, enhancements and development process
- Latency-focused QoS for kernel devices - implementation and experiments
- A lacking policy for power/perf-management of NVMe/UFS/eMMC/SD storage
The key people we would like to participate in the session are Rafael Wysocki, Ulf Hansson, Daniel Lezcano, Lukasz Luba, Srinivas Pandruvada, and Viresh Kumar.
-
Dr Daniel Lezcano (Qualcomm)06/10/2026, 15:00
The Linux thermal framework has proven to be flexible and robust over the years. However, some aspects of its event handling have become increasingly difficult to reason about, resulting in inconsistent behaviors and corner cases.
Examples include trip point updates while the temperature has already fallen within the hysteresis range after the notification was generated, inconsistent...
Go to contribution page -
Dr Daniel Lezcano (Qualcomm)06/10/2026, 15:20
The Linux thermal management and power capping frameworks currently evolve independently, despite relying on the same Energy Model (EM) to describe the power-performance characteristics of devices.
The thermal framework regulates temperature by estimating a sustainable power budget using the power_allocator governor. A PID control loop computes the power reduction required to maintain a...
Go to contribution page -
Srinivas Pandruvada06/10/2026, 15:40
Modern System-on-Chip designs increasingly incorporate built-in hardware thermal controllers to manage thermal conditions efficiently. Intel platforms, beginning with the Lunar Lake generation, feature integrated platform temperature controllers capable of autonomous thermal management. However, not all platform designs directly interface temperature readings and thermal thresholds with these...
Go to contribution page -
Jie Zhan (HiSilicon)06/10/2026, 16:00
SoC uncore components, such as interconnects, system-level caches, and memory controllers, can account for a substantial share of package power, and their operating frequency bounds the achievable bandwidth and latency. Core DVFS is well supported by cpufreq, but there is no generic upstream mechanism for uncore DVFS - a gap felt most on server platforms. We propose building uncore DVFS on top...
Go to contribution page -
Sumit Gupta06/10/2026, 16:40
ACPI CPPC "autonomous selection" lets the platform pick the CPU performance level itself, within OS-provided min/max bounds and guided by an Energy Performance Preference (EPP) hint. Today cppc_cpufreq exposes this as a per-policy auto_select sysfs toggle layered on top of whatever scaling governor is attached. The result is confusing: once autonomous mode is on, the attached governor...
Go to contribution page -
Mr Brian Masney06/10/2026, 17:20
At last year's Linux Plumbers Conference, we had some great discussions about how to fix clock tree propagation in the Common Clk Framework (https://lpc.events/event/19/contributions/2152/). Taking that feedback into account, a v8 patch set has been posted that solves the problem in a simple manner.
https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/
The...
Go to contribution page -
Ricardo Neri (Intel Corporation)06/10/2026, 17:50
The scheduler's task wake-up logic and capacity-aware load balancing rely on arch_scale_cpu_capacity() to determine how much work a CPU can absorb. It also has logic to account for the effects of transient thermal- and power-driven capacity loss. This mechanism, known as hardware pressure, is currently not used on x86: arch_scale_cpu_capacity() returns a fixed constant on non-hybrid systems,...
Go to contribution page -
Samuel Wu (Google)06/10/2026, 18:10
Transitioning a CPU into and out of idle has a non-negligible energy overhead. This "wakeup tax" is frequently triggered by background tasks with low utilization but a high number of wakeups. Furthermore, these tasks largely escape detection from existing energy-aware mechanisms like PELT and EAS, which are optimized for continuous execution rather than transient hardware states.
This talk...
Go to contribution page