@Pete-S said in Geekbench observations:
@dafyre said in Geekbench observations:
@Pete-S said in Geekbench observations:
The relationship between the single-core and multi-core score should be about 80% of theoretical max on the multi-core score.
So if single core score is 3000 and you have 4 vCPUs then multi-core score should be 80% of 3000 x 4 cores = 9600. If the host is under heavy load the multi-core score will go lower and lower.
I think you are on the right track. This is largely in part due to how the underlying Hypervisor handles multi-core VMs. The way I understand it, is that in a multi-core VM, the Hypervisor has to wait for that number of cores to be ready to process before it signals to the VM that it can keep running.
IE: In your example, a 4 core VM, the underlying hypervisor will have to wait to have 4 cores waiting for work before it will tell the VM that it's cores are available.
I've read that before but I think it is some old feature of very old hypervisors called strict co-scheduling. It's not used anymore.
Nowadays basically every hypervisor has their scheduler that puts vCPU on real pCPUs according to the time share principle. So every vCPU get's a piece of the pie. But it has to account for hyperthreading, more than one CPU socket (NUMA), power saving, VM priority and other things. The underlying principle is though that all VMs and their vCPUs should get their fair share of CPU time.
Some hypervisors have different scheduler algorithms so you can pick other ways of scheduling that might be more optimized for your workload.
Depends, SMP doesn't really allow for that, all cores have to be in lock step. Only is AMP is supported can the hypervisor do that. It requires the hypervisor and system above it together to do non-SMP processing.
