Fixing Real-Time Scheduler Throttling in the Linux Kernel
summary
Problem: Linux RT throttling is too aggressive for ChromeOS/Android workloads, starving UI threads while leaving CPUs idle. Kernel changes keep throttled RT tasks on the runqueue and allow them to run on idle CPUs or be demoted to time‑share, and an alternative uses a fake SCHED_DEADLINE server to guarantee CFS bandwidth. Measurements use ftrace and a Chrome/Chromebook workload and show 32% lower mouse latency by making key threads RT; default policy reserves 95% RT budget for realtime. Patches work but are not yet fully upstream.
AI-written summary · about
chapters (4)
- 0:00Start
- 18:13Old RT throttling design
- 19:33Fixing RT throttling: First attempt!
- 28:45Fixing RT throttling: Deadline server
related talks
51mTuning RT Kernel to Improve Schedule Performance with Intel Platform
47mReal-Time Linux: What Is Next?
25mLinux needs a Scheduler QOS API -- and it isn't nice(2)
02h 08mTutorial: Leveraging the OS CPU Scheduler to Write Real-Time MT Apps- 51mTuning RT Kernel to Improve Schedule Performance with Intel Platform
40mRT Linux in Safety-Critical Systems: The Potential and the Challenges
50mrtla timerlat: Debugging Real-Time Linux Scheduling Latency
52mEffectively Measure and Reduce Kernel Latencies for Real-time Constraints