A High-Level Quality-of-Service Interface for Linux

The Linux scheduler has long been optimized for server throughput, but the demands of modern computing—from interactive laptops to battery-powered devices—require a different approach. At the 2025 Linux Plumbers Conference, a team including Qais Yousef, John Stultz, Steven Rostedt, and Vincent Guittot presented a proposal for a high-level quality-of-service (QoS) interface that would allow applications to communicate their performance expectations to the kernel without needing to understand the intricate details of the EEVDF scheduler.

The core problem is that the current scheduler operates reactively, making decisions based on observed behavior rather than anticipated needs. Applications often spawn threads assuming exclusive access to CPU cores, a legacy assumption from a server-centric era that doesn't reflect the reality of multi-tasking personal devices. While the EEVDF scheduler offers numerous configurable parameters—time slices, policies, ramp-up multipliers, and uclamp settings—these are typically tuned system-wide or per-process by experts, not by application developers or end users.

The proposed solution borrows directly from Apple's QoS system, which defines four distinct classes: user interactive (for UI updates), user initiated (for active user tasks), utility (for prompt but non-interactive tasks), and background (for non-critical work). Each class would map to specific scheduler parameters. Interactive threads would receive shorter time slices, prioritizing latency over throughput, ensuring UI responsiveness. Background tasks would get longer time slices, allowing them to run uninterrupted when the system is idle but be preempted immediately when higher-priority work appears. The utility class would serve as the default, matching current scheduler behavior.

This mapping isn't merely theoretical. The team outlined concrete changes to the kernel's task placement logic. Currently, the load balancer chooses CPUs based on load, energy usage, NUMA domains, or core affinity. With QoS classes, it could consider the task's nature: placing a latency-sensitive thread on an idle CPU for immediate execution, or on a CPU handling long-running tasks where it can be easily preempted. This requires extending the balancer's decision matrix to incorporate task characteristics alongside system state.

A significant portion of the discussion centered on adoption strategy. Historical experience shows that new kernel APIs can take years to gain traction if they require explicit code changes. The proposal suggests a configuration-file-based approach instead. Applications could ship default configurations, but users and distribution maintainers could override them. This keeps ultimate control with the system owner—if an application requests inappropriate priorities, the user can adjust them. The kernel would also implement access control, potentially restricting an application's claimed QoS class based on context (e.g., foreground status detected via control groups or desktop environment hints).

The conference audience raised important counterpoints. One attendee questioned why the system should be "fair" to batch jobs, suggesting that foreground UI work should receive near-absolute priority. The response clarified that EEVDF's virtual deadline mechanism inherently prioritizes interactive tasks: shorter time slices mean earlier deadlines, so UI threads preempt background work as soon as they become runnable. The fairness comes from ensuring background tasks still make progress when idle, rather than being starved completely.

Another thread of discussion addressed the relationship to existing mechanisms. Linux already has deadline scheduling and nice levels for prioritization, but these require root privileges or detailed knowledge to use effectively. The QoS API aims to provide a higher-level abstraction for unprivileged applications. As one commenter noted, the existing frameworks are designed for omnipotent administrators, not for applications that need to express nuanced performance requirements.

The proposal also intersects with ongoing work on performance inheritance—preventing priority inversion where a high-priority task waits for a low-priority one holding a lock. By allowing tasks to "donate" CPU time or QoS class to blocked threads, the system could further reduce latency, complementing the QoS classes.

For heterogeneous systems like ARM's big.LITTLE, the QoS classes could inform energy-aware scheduling. A background thread might be directed to efficient cores to save power, while a UI thread would prefer performance cores for responsiveness. The interface could even be extended to let tasks specify whether they're willing to pay a power premium for faster completion.

The broader implication is a shift in Linux's design philosophy. For decades, the kernel has been optimized for servers, where throughput is king. The increasing importance of interactive devices—phones, laptops, embedded systems—demands equal attention to latency and user experience. A standardized QoS API would give developers a simple way to communicate their application's needs, while letting the kernel make intelligent trade-offs based on system context.

Whether Linux adopts this specific proposal remains uncertain, but the direction is clear. The kernel's scheduling subsystem is evolving beyond pure throughput optimization, and providing a high-level interface for performance hints could be a crucial step toward making Linux more responsive across all device categories. The configuration-file approach offers a pragmatic path to adoption, balancing application developer convenience with user control. As one attendee summarized, the goal is to give the scheduler more information to make better decisions, not to enforce rigid priorities.

The discussion also highlighted a fundamental tension in system design: how much should applications reveal about their internal structure, and how much should the kernel infer? The QoS classes represent a middle ground—applications provide hints about their intent (interactive, background, etc.), and the kernel uses those hints to optimize scheduling without being bound by them. This collaborative approach could lead to systems that are both more performant and more predictable for users.

Ultimately, the proposal reflects a maturing understanding of what modern computing demands. It's not enough for the kernel to be efficient; it must also be responsive, fair, and adaptable. By borrowing proven concepts from other operating systems and adapting them to Linux's unique architecture, this QoS interface could help bridge the gap between server-optimized infrastructure and the diverse needs of today's computing landscape.