-
Notifications
You must be signed in to change notification settings - Fork 216
Description
I'm on a laptop with awful cooling [1]; consequently, my available compute is usually thermals-limited. While the Intel SpeedStep machinery does an adequate job of keeping the core and package temperatures inside thermal boundaries, it can do so only by lowering clocks. The lowered clocks reduce overall performance.
When I'm running a compute-bound workload (e.g. a kernel compile) in the background, the clocks can sometimes go so low, below even 600Mhz, that interactive tasks like my Wayland compositor, browser, etc. have lag and stutter. Tweaking kernel thread scheduling doesn't help: with clocks this low, there's just not enough compute available for an adequate desktop experience even if the scheduler does its best to give interactive tasks priority access to the compute I do have. I can manually duty-cycle batch workloads or affinitize them to a subset of cores, but I shouldn't have to --- and it's not always obvious when I'm about to enter this CPU-bound regime. (Is this cargo command going to exit in 10 seconds or 10 minutes? Who knows up front?)
The ideal way to address the problem of batch loads forcing thermal throttling that makes GUI unusable is for the kernel scheduler to limit long-running batch loads before thermal throttling kicks in, leaving thermal headroom for bursty interactive workloads. sched_lavd and other schedulers already know which tasks are interactive.
A sufficiently smart scheduler can put the system under closed-loop thermal control: when it detects the system is about to hit its thermal limits, it can throttle non-interactive tasks first, before lower-level firmware throttling kicks in, so that when an interactive task becomes runnable, we have spare cycles for it.
I don't think this throttling would necessarily even hurt batch throughput: as a quick experiment, a kernel compile affinitized to only my E-cores completed in about the same time as an unaffinitized one running across all cores --- but in the former case, my GUI loads were able to run on my P-cores and the system as a whole felt more responsive.
Do you think this kind of closed-loop thermal management is something that would be appropriate for LAVD?
[1] X1C 10th generation; CPU is a 12th Gen Intel(R) Core(TM) i7-1280P.