The link is not for QEMU/KVM and some generic boilerplate that isn't helping at all for the distinction of vCPU's and CPU units (a scheduler knob) that the original post asked about, or what does this link answers?
[SOLVED] Sockets vs Cores vs Threads vs vCPU vs CPU Units
- Thread starter ahriman
- Start date
-
- Tags
- cpu sockets threads vcpu
Thanks, it asks the sames questions that I posed. However, in the age of generative AI, I can't help but find the maths is a little questionable
(8 Cores x 16 Threads) x 1 CPU = 128 vCPUs
How would KVM be able to schedule all 100 vCPUs at the same time when there are only 16 actual threads? That's why the number of virtual cores (per socket) is limited to the number of physical threads. If you want your VMs to run smoothly, you should run your VMs with 8 virtual cores or less.
EDIT: I learned that this is not a KVM limitation but a reasonable PVE one.
Last edited:
Actually, the maximum number of vCPUs could be higher for KVM (NR_MAX_CPUs, i.e., what the kernel would support as maximum CPU count for the actual physical CPUs its running on).
But yes, it makes no sense whatsoever to have more vCPUs than there are CPU threads available, with that one is just making the scheduler run in cycles and waste CPU power on cycling through the extra cores.
That's why we block such over-allocation explicitly on a Proxmox VE management level, as this makes performance a lot worse, and if unnoticed it might be harder to debug for users.
Depending on what the host itself has to do, or if there are other guests, a smaller vCPU makes sense to avoid all to high CPU pressure overall.
But yes, it makes no sense whatsoever to have more vCPUs than there are CPU threads available, with that one is just making the scheduler run in cycles and waste CPU power on cycling through the extra cores.
That's why we block such over-allocation explicitly on a Proxmox VE management level, as this makes performance a lot worse, and if unnoticed it might be harder to debug for users.
Depending on what the host itself has to do, or if there are other guests, a smaller vCPU makes sense to avoid all to high CPU pressure overall.
AFAIK, for the kernel to schedule a VM to run, it has to wait until the number of vCPU configured in the VM are free, so the host's kernel can schedule all to run at the same time. So for a 4 vCPU VM to run, there has to be 4 hosts CPUs free, otherwise the kernel has to wait to schedule that VM execution. The wait may be very short, of course. This is why I set vCPU a low as possible for all VMs in a host.
Am I right?
for KVM/Qemu, vCPUs are "just" threads that are scheduled however the kernel is configured. you can optimize performance by limiting/avoiding overcommiting, pinning vCPU threads, adjusting scheduler and NUMA-related settings, .. and of course, there are certain optimizations in the code as well (in the guest kernel and Qemu) to avoid deadlocking by inter-vcpu dependencies (or at least reduce the chance of triggering one, unless you are gravely overcommitted).
I'm late to this thread and don't understand fully, I'm not very technical :/
I have the same issue i think:
Let's say I have 5 vms. Just say I have 2 cores and 8 threads total (4 threads per core).
Iv have tried to explain with pictures (and I know I forgot to put in proxmox requirements just forget them for a bit) how would I allow my "some docker thing vm" to use the rest of the server resources manually (NOT AUTOSCALE)? Would I just change the core count to 3 from 1? Thanks for any answers
(i just want to increase the resources that docker has to boost it performance for a bit)
I have the same issue i think:
Let's say I have 5 vms. Just say I have 2 cores and 8 threads total (4 threads per core).
Iv have tried to explain with pictures (and I know I forgot to put in proxmox requirements just forget them for a bit) how would I allow my "some docker thing vm" to use the rest of the server resources manually (NOT AUTOSCALE)? Would I just change the core count to 3 from 1? Thanks for any answers
(i just want to increase the resources that docker has to boost it performance for a bit)
Yep, probablyvery exotic. Dont know much about this tuff srry. And no, it's not. Its 4 socket 18 core per socket and 2 thread per core. But I'm trying to keep specs simple. The core and the thread count doesn't really matter I don't think.
Last edited: