LWN: Comments on "Telling the scheduler about thermal pressure"

Telling the scheduler about thermal pressure

oak — Tue, 04 Jun 2019 17:06:36 +0000

TDP limits act are in my experience clearly faster than temperature limits. Heat takes some time to spread / dissipate whereas TDP limits are calculated and enforced (by firmware) based on HW counters of what HW is doing at given moment, it doesn’t need to wait for the effects of that activity.

Telling the scheduler about thermal pressure

admalledd — Fri, 17 May 2019 15:29:15 +0000

My (naive!) understanding is that these specific thermal pressure events are very short lived, and can also be per-core. The scheduler already would take into account general frequency reduction over a longer term reasonably well, it is the rapid thermal reaction of cutting frequency drastically that is being added here specifically.

Telling the scheduler about thermal pressure

ScienceMan — Thu, 16 May 2019 22:14:19 +0000

There are many other mechanisms that can result in frequency capping beyond just thermal events. In laptops, for example, reducing processor frequency is a standard method to reduce overall power drawn by the cpu, and more generally, interfaces like the Intel RAPL mechanism can be used to enforce power limits that result in cpu frequency throttling. Some batch job control systems, e.g. slurm, include capabilities to set power limits using these features.

Is there something specific about the Linux scheduler under conditions of thermal pressure that makes it necessary to adjust features of the kernel when cpu frequency is reduced? I don't think any of the above examples pay any attention to this if so.

Here are a couple of more or less randomly chosen references to ways that power capping is used in HPC systems, for example.

http://eethpc.net/wp-content/uploads/2018/06/Slurm-Power-...

https://www.scirp.org/journal/PaperInformation.aspx?Paper...