Speakers
Description
As production workloads increasingly transition to virtual machines for security isolation and resource consolidation in multi-tenant environments, traditional CPU scheduling faces a critical M:N preemption challenge. The host operating system schedules opaque virtual CPUs rather than the actual workload threads. Consequently, the host scheduler remains blind to the varying priorities and latency sensitivities of the guest threads running inside the VM. This leads to severe priority inversion; for instance, the host scheduler cannot differentiate between a vCPU running a low-priority batch or kernel system thread and one executing a latency-sensitive task (such as a critical helper daemon) nested within the same VM. Consequently, critical latency-sensitive work is starved, and physical resources are wasted under host CPU contention.
To resolve this, we propose a bidirectional VM Scheduling Passthrough architecture to bridge the VM boundary from a scheduling perspective. This model relies on cooperative, paravirtualized communication to enable host-side awareness and control:
1. Guest-to-Host: The guest kernel exposes scheduling metadata (potential signals include thread-level priorities and latency requirements) to the host.
2. Host-to-Guest / Host Control: The host leverages these guest signals to either (a) intelligently prioritize the execution of a given vCPU, or (b) in a more complete solution, directly select both the vCPU and the specific guest thread running on that vCPU to execute (this latter proposal is more aspirational, and would effectively give the host full scheduling control over the guest, voiding the need for guest scheduling or load balancing).
Implementing such a model requires a clean separation of mechanism and policy. In line with upstream maintainer feedback, KVM should remain policy-free, acting purely as the communication conduit. We propose sched_ext as the ideal framework to house the scheduling policy, and pvsched as the communication mechanism to share data between host and guest. Running the policy in a host BPF scheduler allows for rapid iteration and workload-specific customization without modifying KVM or the core kernel.
Current upstream efforts, notably the IBM patch series "Introduce cpu_preferred_mask and steal-driven vCPU backoff", attempt to address host preemption purely from the guest side. In this model, the guest monitors hypervisor steal time and flags heavily preempted vCPUs as "non-preferred" to guide guest-side task migration. While this provides a defensive mechanism, it is unidirectional and reactive. Furthermore, as highlighted by upstream maintainers, this approach faces significant limitations: it risks embedding scheduling policy within the hypervisor, and in high-overcommit scenarios where steal time is elevated across all cores, the guest-side mask degrades, leaving the guest scheduler with no viable execution targets.
pvsched (https://github.com/pvsched/) has undergone some discussion on the list already, and v3 is being prepared.
In this session, we want to discuss:
- Interface Design: The updates in pvsched v3
- sched_ext Integration: How sched_ext can ingest these guest signals to influence host scheduling decisions, and conversely, how it can export host scheduling desires back to the guest