3 ms·

The conflict between the market wanting systems that are (a) as small and light as possible and (b) as fast as possible means that modern systems are designed t

by mjg59 5y ago

The conflict between the market wanting systems that are (a) as small and light as possible and (b) as fast as possible means that modern systems are designed to have close integration between the platform and the OS to perform appropriate thermal management. If the OS doesn't indicate that it supports doing this, the hardware will run in a much more constrained mode. Apple can do this without too much trouble since they implement the whole stack, but it's more complicated in the PC space. Intel have a spec called Dynamic Power and Thermal Framework (DPTF), but the useful part of it is the adaptive thermal policy, and Intel refuse to publicly document it. I reverse engineered a chunk of this (https://mjg59.dreamwidth.org/54923.html https://mjg59.dreamwidth.org/54923.html) and it got merged into Intel's Thermal Daemon (https://github.com/intel/thermal_daemon https://github.com/intel/thermal_daemon) which /should/ improve things, but it's complicated by this mechanism allowing for vendor-specific controls that are usually implemented by having a background service running under Windows that triggers them. There's multiple things that can be criticised here: 1) Intel pushing OEMs to adopt a technology that they (a) don't document and (b) don't write proper Linux support for 2) Canonical not making it clear that OEM certification only requires that the system work, not that it work as well as it does under Windows 3) Dell not figuring out a decent solution for this, even for systems that they nominally support Linux on Dell could build hardware that doesn't rely on adaptive thermal management, but that hardware would either be bigger or slower than competitors' hardware. Fixing this unilaterally is hard - we need an open spec that's implemented by both hardware vendors and integrated into mainstream Linux distributions. Given where we are, the easiest way to get there would be for Intel to publicly document DPTF.

michaelt 5y ago
> modern systems are designed to have close integration between the platform and the OS to perform appropriate thermal management. What does this mean in practice for a standard laptop? I mean, every laptop supports the classic "turn up fans when CPU gets hot" and "throttle CPU if it gets very hot" - is that not sufficient to let the CPU operate as fast as the laptop's thermal design will permit?
- horsawlarway 5y ago
  no, unfortunately it's nowhere close to sufficient. Power management on various chips is a complicated subject, and most modern laptops do a LOT of things to try to draw out battery life as long as possible. If you want just a brief idea - take a look at https://wiki.archlinux.org/title/Power_management https://wiki.archlinux.org/title/Power_management If it helps, you can think of thermal management and battery management as directly related (that heat is coming from somewhere, and it's the battery in the laptop - the more heat, the more energy being consumed [or wasted].)
- mjg59 5y ago
  Trivial example: you want to avoid the exterior of the laptop getting hot enough to be uncomfortable for the user. If you support adaptive policies, you can read the skin temperature sensor and then only throttle the CPU if that's above a certain temperature. If you want to get more fancy, you can make that temperature conditional on whether there's a dock attached or not (if the machine's sitting on the desk then the bottom temperature can go higher than it could otherwise). More complex example: the wifi chipset also produces heat. The platform designer should take into account what the effect of CPU thermal output is on the wifi chipset, and expose that information in a way that the OS can make a decision about whether the appropriate response is to throttle the CPU or allow the wifi chipset to throttle itself. Making that decision is going to depend on the current workload, so you don't want to try to implement this in firmware. If you don't support adaptive policies, then you just restrict the CPU such that even under worst case scenarios, the components can never exceed the desired temperature. Of course, this means that you're (generally) running slower than necessary.
viraptor 5y ago
Have the kernel patches you mentioned in the post been merged already in some form? Or is that required for a hacky solution?
- mjg59 5y ago
  They're merged, and if you're running a current version of Thermal Daemon then things /should/ be better than they were. But most policies don't actually explicitly modify the throttling temperature MSR, and Windows definitely defaults to a different value there when compared to Linux, so there's something more going on.
mattst88 5y ago
Exactly. When I was at Intel (working on the Mesa 3D drivers for Linux) we would routinely get reports that performance was less than on Windows and ultimately determine it was because on Windows the thermal limits would be set to e.g. 45W but on Linux we'd be stuck at 35W.

by mjg59 5y ago

michaelt 5y ago

> modern systems are designed to have close integration between the platform and the OS to perform appropriate thermal management. What does this mean in practice for a standard laptop? I mean, every laptop supports the classic "turn up fans when CPU gets hot" and "throttle CPU if it gets very hot" - is that not sufficient to let the CPU operate as fast as the laptop's thermal design will permit?

horsawlarway 5y ago
no, unfortunately it's nowhere close to sufficient. Power management on various chips is a complicated subject, and most modern laptops do a LOT of things to try to draw out battery life as long as possible. If you want just a brief idea - take a look at https://wiki.archlinux.org/title/Power_management https://wiki.archlinux.org/title/Power_management If it helps, you can think of thermal management and battery management as directly related (that heat is coming from somewhere, and it's the battery in the laptop - the more heat, the more energy being consumed [or wasted].)
mjg59 5y ago
Trivial example: you want to avoid the exterior of the laptop getting hot enough to be uncomfortable for the user. If you support adaptive policies, you can read the skin temperature sensor and then only throttle the CPU if that's above a certain temperature. If you want to get more fancy, you can make that temperature conditional on whether there's a dock attached or not (if the machine's sitting on the desk then the bottom temperature can go higher than it could otherwise). More complex example: the wifi chipset also produces heat. The platform designer should take into account what the effect of CPU thermal output is on the wifi chipset, and expose that information in a way that the OS can make a decision about whether the appropriate response is to throttle the CPU or allow the wifi chipset to throttle itself. Making that decision is going to depend on the current workload, so you don't want to try to implement this in firmware. If you don't support adaptive policies, then you just restrict the CPU such that even under worst case scenarios, the components can never exceed the desired temperature. Of course, this means that you're (generally) running slower than necessary.

viraptor 5y ago

Have the kernel patches you mentioned in the post been merged already in some form? Or is that required for a hacky solution?

mjg59 5y ago
They're merged, and if you're running a current version of Thermal Daemon then things /should/ be better than they were. But most policies don't actually explicitly modify the throttling temperature MSR, and Windows definitely defaults to a different value there when compared to Linux, so there's something more going on.

mattst88 5y ago

Exactly. When I was at Intel (working on the Mesa 3D drivers for Linux) we would routinely get reports that performance was less than on Windows and ultimately determine it was because on Windows the thermal limits would be set to e.g. 45W but on Linux we'd be stuck at 35W.