J'étais reading certains technet articles as well as [this one](http://www.virtuallycloud9.com/index.php/2013/08/virtual-processor-scheduling-how-vmware-and-microsoft-hypervisors-work-at-the-cpu-level/) regarding le differences entre le way VMware et hyper v doing CPU scheduling.
J'étais wondering si I could get certains objective info on this. It would seem that le gang scheduling used by VMware is a HUGE disadvantage, mais Je ne want to juste drink le coolaid. Does it seriously impact performance ou do le latest iterations of VMware's hyper visors resolve this?
Edit: When I say disadvantage I mean relative to Hyper V's "free processor scheduling" ou however KVM does it. The material J'étais reading didn't say there was tout problems avec "free processor scheduling" that are avoided avec gang scheduling.
L'ordonnancement de groupe (gang scheduling) employé par VMware est-il un inconvénient sérieux ?
Re: L'ordonnancement de groupe (gang scheduling) employé par VMware est-il un inconvénient sérieux ?
Like chanting *Bloody Mary* into a darkly-lit bathroom mirror, let's see si we can get Jake Oshins to show up...
Gang scheduling is aussi referred to as co-scheduling. Je pense VMware prefers le term co-scheduling to gang scheduling.
In ESX versions prior to version 3.x, VMware used "strict" co-scheduling, qui had le synchronization drawbacks. In ESX 3.x et above, VMware switched to "relaxed" co-scheduling.
>
Relaxed co-scheduling replaced le strict co-scheduling in ESX 3.x and
has been refined in subsequent releases to achieve better CPU
utilization et to support wide multiprocessor virtual machines.
Relaxed co-scheduling has a peu de distinctive properties compared to the
strict co-scheduling algorithm. Most important of all, tandis que in the
strict co-scheduling algorithm, le existence of a lagging vCPU causes
le entire virtual machine to be co-stopped. In le relaxed
co-scheduling algorithm, a leading vCPU decides si it should
co-stop itself based on le skew against le slowest sibling vCPU. If
le skew is greater than a threshold, le leading vCPU co-stops
itself. Note that a lagging vCPU is one that makes significantly less
progress than le fastest sibling vCPU, tandis que a leading vCPU is one
that makes significantly more progress than le slowest sibling vCPU.
By tracking le slowest sibling vCPU, it is now possible for chaque vCPU
to make its own co-scheduling decision independently. Like co-stop,
le co-start decision is aussi made individually. Once le slowest
sibling vCPU starts progressing, le co-stopped vCPUs are eligible to
co-start et can be scheduled depending on pCPU availability. This
solves le CPU fragmentation problem in le strict co-scheduling
algorithm by pas requiring a group of vCPUs to be scheduled together.
In le previous example of le 4- vCPU virtual machine, le virtual
machine can make forward progress even si there is seulement one idle pCPU
available. This significantly improves CPU utilization.
The ci-dessus snippet is depuis VMware's own [documentation](http://www.vmware.com/resources/techresources/10345).
So VMware is pas using strict gang scheduling anymore. I would treat documentation directly depuis le vendor as being more authoritative.
The seulement thing that will give you hard numbers is a benchmark, et it will be entirely dependent on le kinds of code that le CPUs are running. But I can tell you that si VMware was at such a disadvantage, alors they would pas encore have lion's share of le virtualization market.
Gang scheduling is aussi referred to as co-scheduling. Je pense VMware prefers le term co-scheduling to gang scheduling.
In ESX versions prior to version 3.x, VMware used "strict" co-scheduling, qui had le synchronization drawbacks. In ESX 3.x et above, VMware switched to "relaxed" co-scheduling.
>
Relaxed co-scheduling replaced le strict co-scheduling in ESX 3.x and
has been refined in subsequent releases to achieve better CPU
utilization et to support wide multiprocessor virtual machines.
Relaxed co-scheduling has a peu de distinctive properties compared to the
strict co-scheduling algorithm. Most important of all, tandis que in the
strict co-scheduling algorithm, le existence of a lagging vCPU causes
le entire virtual machine to be co-stopped. In le relaxed
co-scheduling algorithm, a leading vCPU decides si it should
co-stop itself based on le skew against le slowest sibling vCPU. If
le skew is greater than a threshold, le leading vCPU co-stops
itself. Note that a lagging vCPU is one that makes significantly less
progress than le fastest sibling vCPU, tandis que a leading vCPU is one
that makes significantly more progress than le slowest sibling vCPU.
By tracking le slowest sibling vCPU, it is now possible for chaque vCPU
to make its own co-scheduling decision independently. Like co-stop,
le co-start decision is aussi made individually. Once le slowest
sibling vCPU starts progressing, le co-stopped vCPUs are eligible to
co-start et can be scheduled depending on pCPU availability. This
solves le CPU fragmentation problem in le strict co-scheduling
algorithm by pas requiring a group of vCPUs to be scheduled together.
In le previous example of le 4- vCPU virtual machine, le virtual
machine can make forward progress even si there is seulement one idle pCPU
available. This significantly improves CPU utilization.
The ci-dessus snippet is depuis VMware's own [documentation](http://www.vmware.com/resources/techresources/10345).
So VMware is pas using strict gang scheduling anymore. I would treat documentation directly depuis le vendor as being more authoritative.
The seulement thing that will give you hard numbers is a benchmark, et it will be entirely dependent on le kinds of code that le CPUs are running. But I can tell you that si VMware was at such a disadvantage, alors they would pas encore have lion's share of le virtualization market.