Linux needs a Scheduler QOS API -- and it isn't nice(2)
summary
Argues Linux needs a scheduler QOS API that accepts per-thread QoS hints (background / user-interactive / user-initiated) so Chromium can map its thread classes across OSes; surveys existing tools like uclamp, sched_deadline, sked-idle and cgroups, and hardware knobs (per-core frequency, cache/MEM QoS) and reports no working cross-platform solution today. Proposes exporting hardware capability info and a lightweight mechanism to attach hints to tasks while keeping policy in user space via a library or middleware.
AI-written summary · about
chapters (6)
- 0:00Introduction and context
- 3:09Current Linux limitations
- 8:25Chromium's needs and goals
- 13:18Cgroups vs direct API
- 19:55Middleware and user space solutions
- 24:30Policy in kernel vs user space
related talks
38mFixing Real-Time Scheduler Throttling in the Linux Kernel
46mOptimizing Scheduler for Linux Gaming
02h 08mTutorial: Leveraging the OS CPU Scheduler to Write Real-Time MT Apps
32mImprove CPU Utilization by Designing a New Schedule Algorithm
23mSCHED_DEADLINE desiderata and slightly crazy ideas
32mImprove CPU Utilization by Designing a New Schedule Algorithm
19msystem pressure on CPUs capacity and feedback to scheduler
35mOpening the Box: Diagnosing Operating-System Task-Scheduler...