system pressure on CPUs capacity and feedback to scheduler
summary
Proposes adding a new kernel interface rscale_cpu_cap that reports sustainable CPU capacity for the next ~10–100 ms, distinct from existing rscale_cpu_capacity (max) and averaged rscale_thermal_pressure. Patches are nearly ready and a patchset will be published before LPC as a follow-up to OSPM. Scheduler uses the minimum of user cap, firmware/thermal caps and current frequency; changes touch load-tracking and deadline server, require replacing blocking notifiers, and rely on firmware hooks like scmi and lmh for real-time feedback.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:08CPU capacity factors
- 3:56Current scheduler interfaces
- 6:03User space frequency scaling
- 8:55Sustainable capacity proposal
- 11:25Firmware and thermal pressure
- 13:55Hardware mitigation feedback
- 16:25Unified pressure interface
- 17:29Virtual machine contention
- 18:33Real-world firmware examples
- 19:14Summary and Q&A
related talks
32mImprove CPU Utilization by Designing a New Schedule Algorithm
40mA New CPU Frequency Control Mechanism on Linux
40mLatency hints for CFS task
50mFrequency-invariance gaps in current kernel
25mLinux needs a Scheduler QOS API -- and it isn't nice(2)
44mRestartable Sequences: Scheduler-Aware Scaling of Memory Use on Many-Core Systems
52mEffectively Measure and Reduce Kernel Latencies for Real-time Constraints
32mImprove CPU Utilization by Designing a New Schedule Algorithm