Frequency-invariance gaps in current kernel
summary
Kernel uses a boot-time frq_max set at boot heuristic that often misrepresents available CPU capacity on Intel and hybrid systems; experiments run two workloads on cpu0/cpu2 with cpu2 frequency capped show reported utilization collapsing to ~25% even though workrate stays constant. Root causes include turbo bins, changing TDP limits and aperf/rtc ratio > 1 skewing frequency-derived task size. Proposed fix is to derive recent effective max by saturating the core and sampling actual frequency (and add per-core microarch scaling); prototype discussion spans a 30‑patch rework and tuning of load‑balancer heuristics.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 1:41Load balancer frequency issues
- 3:49Frequency-invariance gaps problem
- 13:34Thermal and turbo frequency limits
- 25:43Thermal zone device API changes
- 32:56API simplification proposal
- 35:06Frequency invariance on x86
- 40:13Micro-architecture capacity differences
- 47:40Thermal pressure and utilization
related talks
19msystem pressure on CPUs capacity and feedback to scheduler
51mTuning RT Kernel to Improve Schedule Performance with Intel Platform
32mImprove CPU Utilization by Designing a New Schedule Algorithm
16mXkernel: Principled Performance Tunability of Operating System Kernels
40mA New CPU Frequency Control Mechanism on Linux- 51mTuning RT Kernel to Improve Schedule Performance with Intel Platform
52mEffectively Measure and Reduce Kernel Latencies for Real-time Constraints
19mDo nothing fast: How to scale idle cpus?