De: "Dominique Ramaekers" <[email protected]>
À: "Troels Arvin" <[email protected]>, [email protected]
Envoyé: Lundi 8 Septembre 2025 16:29:39
Objet: RE: Co-stop with non-VMware virtualization?
Hi Arvin,
If you don’t do cpu-pinning and you overcommit cpu resources. KVM will schedule
cpu load to best effort. I always overcommit cpu resources because vcpu’s are
rarely on 100% load and KVM will divide actual vcpu load over the physical
cpu’s. On rare occasions there is not enough physical capacity available and
the users notice ‘lag’ on the systems. I think VMware does the same and co-stop
is just a performance metric to measure this effect, but I’m not well known
with VMware. I found this post though: [
https://blog.leaseweb.com/2023/01/10/performance-metrics-in-vmware/ |
https://blog.leaseweb.com/2023/01/10/performance-metrics-in-vmware/ ]
Greetings,
Dominique.
Van: Troels Arvin via Users <[email protected]>
Verzonden: maandag 8 september 2025 15:05
Aan: [email protected]
Onderwerp: Co-stop with non-VMware virtualization?
Hello,
How important is it to consider "co-stop" with non-VMWare virtualization such
as KVM?
I haven't been able to find anything about this for KVM, but there's some
material about it for VMWare (albeit typically rather old material). Based on
VMWare material, by "co-stop" I mean the following situation:
A VM called "x" has been assigned quite a few vCPUs, e.g. 10, on a hypervisor
with e.g. 20 physical cores. The hypervisor is hosting many other VMs, and the
many VMs take turn running on the hardware.
Now, if it's often the case that, e.g., only 7 physical threads are available
when it's x's turn to run, the hypervisor needs to postpone running x till all
10 cores can be allocated at the same time. During this waiting time, x is
stopped (co-stop).
Is my understanding correct? Or will KVM allow x to run on (e.g.) 7 cores, even
though the VM thinks it has 10 vCPUs available?
It's my understanding that with KVM, the co-stopped situation is reflected in
the VM's "steal time" metric in a tool like "top".
Does hyperthreading in either the hypervisor and/or the guest impact the risk
of co-stop?
--
Regards,
Troels Arvin
