This proposal is to gather hackers interested in improving the thermal subsystem in the Linux Kernel and its interaction with hardware and userspace based policies. Nowadays, given the nature of the workloads and the wide spectrum of devices that Linux is used into, the peers interested in improving the thermal subsystem come from different backgrounds and with use cases of diverse thermal constrained systems, ranging from embedded devices to systems with high computing power. Despite the heterogeneity of software solutions to control thermals, the thermal subsystem is still core of many of them, including policies that rely on hardware configured thresholds, or interactions with firmware based control loops, or even policies that rely on userspace daemons. Therefore, this micro conference aims on gathering the thermal interested developers of the community to discuss further improvements of the Linux thermal subsystem.
The current interfaces for thermal sysfs are really designed for mostly debug and not optimized to handle thermal events in user space. The current notification mechanism using netlink sockets is slow and adds additional computation and latency. The same things hold true for sysfs based reading of temperature, which needs constant polling to identify
In the past I proposed bridge to...
Discuss the following topics:
- thermal framework does not handle disabled thermal zones properly. For example, when a thermal zone is disabled, thermal framework may still poke the thermal sensor, plus, the per-thermal-zone polling timer never stops working for the disabled thermal zone.
- thermal framework does not support registering a disabled thermal zone (which would be enabled later)...
Discussion around some mobile usecases that don't fit very well in the current framework and proposals for possible solutions.
These include virtual sensors, heirachical thermal zones, multiple sensor per thermal zone support, extending governors to tackles tempertaure ranges.
Thermal governors can respond to an overheat event for a cpu by capping the cpu's maximum possible frequency. This in turn
means that the maximum available compute capacity of the cpu is restricted. But Linux scheduler is unaware maximum cpu capacity restrictions placed due to thermal
activity. This session aims to discuss potential solution to thermal framework scheduler interactions.
A discussion around using idle injection as a means to do thermal management
A discussion on creating virtual temperature sensors that acts as aggregators for physical sensors, thereby allowing all the framework operations
Discuss miscellaneous topics from the audience and summarize the Thermal MC