All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
"CPU ballooning" is coming to KVM
Small but interesting bit of news:
https://lwn.net/ml/all/[email protected]/
Typical enterprise workloads are combination of bursty and long running;
their average CPU utilization is low, but they require high core counts
during peak transactions. To accommodate this, customers often
use CPU overcommit strategies i.e. configuring VMs with a large number
of virtual CPUs (vCPUs) while backing them with a smaller, shared pool
of physical CPUs (pCPUs). This achieves a high server consolidation
and excellent cost efficiency.However, when multiple such VMs have high utilization simultaneously,
the shared pCPU pool becomes contended. The hypervisor is forced to preempt
one vCPU to run another to maintain fairness. It maybe schedule vCPU of same
VM or different VM. If a vCPU is preempted while holding a lock or
irq disabled section etc, overall forward progress collapses. There are some
mitigation strategies such as yielding the vCPU to lock-holder, but they
don't cover all the cases. In addition there are hidden costs such as cache,
tlb misses, cost of vCPU preemption, host scheduling overheads etc.Under heavy contention, an effective mitigation strategy for workloads
sensitive to vCPU preemption is for guests/VMs to voluntarily fold their
workloads onto a smaller subset of vCPUs. By demanding fewer pCPUs,
the VMs reduce overall host contention, which decreases vCPU preemption
and improves total throughput for the system.
Just like with memory ballooning, this requires guest cooperation. It could have great benefits when used properly, but it can also cause greedy and dishonest hosts to advertise more vCPUs for a low price than they can deliver.
Comments
I should make a tools for this
Of course this will be used for profit. KVM becomes next OpenVZ :-/ .
CPU masking - check
RAM ballooning - check
CPU ballooning - check
Storage ballooning via qcow2 - check
Long live XEN
I do wonder how thats going to work internally in the linux kernel in regards to per-cpu allocations. At a guess theres going to be a persistent memory cost equivalent to the maximum CPUs you have ever onlined.
Theres also lots of assumptions made that CPUs will eventually drain / process queues....
They can already do that. Try:
That will shut down your second core and any thread running on it will be migrated to another CPU before it's disabled (except certain one-per-core kernel threads which will just be terminated).
The only difference is that this allows the host to request that a guess offline one or more CPUs.
Welcome to the era of giant balloons.
YABS will show them, if the benchmark is off, its rigged.
We shall find them and ban them, ban them all.
As with memory ballooning, it's cooperative so you can just blacklist the driver.
I dont know about you but on most of the ARM platforms (I used to be involved support for many non PI SBC) Ive tested that on its pretty damn unstable. Certainly not something to be doing dynamically.
Nested virtualisation.
Long live KVM
It's rock solid on x86, which is what most virtualization hosts are using.
I have never verified this I just assumed it was the same for all. More of an administrator operation than an operation safe for dynamic usage.
Can anyone with an LWN subscription post the share link for https://lwn.net/Articles/1090381/?
https://lkml.org/lkml/2026/4/8/52
Nah the subscriber share link to the LWN article that discusses the change, not the LKML.