Linux kernel developers are considering a new “steal governor” designed to improve performance when multiple virtual machines compete for limited physical CPU resources. The proposal uses the amount of CPU steal time observed inside a guest to dynamically reduce or expand the number of virtual CPUs on which that VM prefers to schedule work.

The feature is primarily aimed at heavily virtualized servers where administrators deliberately assign more virtual CPUs than the host can physically execute at once. Under heavy load, that overcommitment can lead to frequent vCPU preemption, lock-holder delays, cache disruption, and ultimately lower overall throughput.

The latest v11 patch series was posted on August 25, 2026, and its developer has proposed consideration during the Linux 7.3 development cycle, potentially targeting Linux 7.4 for inclusion. This means the feature is still under review and is not part of a stable Linux kernel yet.

What Is CPU Steal Time?

CPU steal time is a concept specific to virtualization.

Imagine a virtual machine has eight vCPUs. From inside that VM, the operating system behaves as though those eight CPUs are available. But those virtual CPUs ultimately need to run on the host’s physical processors.

If several VMs are competing for the same physical CPU resources, the hypervisor may temporarily prevent one VM’s vCPU from running so another VM can use the processor.

The time during which the guest wanted to execute but couldn’t because the hypervisor was using the underlying CPU elsewhere is known as steal time.

High steal time is therefore a useful indication that the physical host is experiencing CPU contention.

The “Noisy Neighbor” Problem

The steal governor is designed primarily to address what virtualization engineers commonly call the noisy neighbor problem.

Consider a server hosting several VMs:

• VM A has 32 vCPUs.
• VM B has 32 vCPUs.
• VM C has 32 vCPUs.
• The physical server has only 64 CPU threads available to those workloads.

That configuration can work perfectly well when the VMs aren’t simultaneously busy.

If all three suddenly become heavily loaded, however, they may collectively request more CPU time than the physical machine can provide.

The hypervisor then has to constantly switch between vCPUs.

Those interruptions can become particularly expensive if a vCPU is preempted while holding a lock or executing another latency-sensitive section of code. Other threads may then wait for a vCPU that isn’t currently being allowed to run.

The result can be counterintuitive: giving the VMs more virtual CPUs can sometimes make the combined workloads slower.