VMware 採用的 gang 調度是一個嚴重的缺陷嗎？
我正在閱讀一些 technet 文章以及這篇關於 VMware 和 hyper v 進行 CPU 調度方式之間差異的文章。
我想知道我是否可以得到一些客觀的資訊。看起來 VMware 使用的 gang 調度是一個巨大的劣勢，但我不想只喝coolaid。它會嚴重影響性能還是 VMware 的虛擬機管理程序的最新迭代解決了這個問題？
編輯：當我說缺點時，我的意思是相對於 Hyper V 的“免費處理器調度”，或者 KVM 做到了。我正在閱讀的材料並沒有說“自由處理器調度”存在任何問題，而這些問題可以通過幫派調度來避免。
就像對著昏暗的浴室鏡子吟唱血腥瑪麗一樣，讓我們看看能不能讓傑克·奧辛斯出現……
群調度也稱為協同調度。我認為 VMware 更喜歡聯合調度這個術語，而不是組調度。
在版本 3.x 之前的 ESX 版本中，VMware 使用“嚴格”的協同調度，這存在同步缺陷。在 ESX 3.x 及更高版本中，VMware 切換到“寬鬆”協同調度。
寬鬆的協同調度取代了 ESX 3.x 中的嚴格協同調度，並在後續版本中進行了改進，以實現更好的 CPU 使用率並支持廣泛的多處理器虛擬機。與嚴格的協同調度算法相比，寬鬆的協同調度具有一些獨特的特性。最重要的是，在嚴格的協同調度算法中，一個滯後的 vCPU 的存在會導致整個虛擬機協同停止。在寬鬆的協同調度算法中，領先的 vCPU 根據與最慢的同級 vCPU 的偏差來決定它是否應該自行協同停止。如果偏差大於門檻值，則領先的 vCPU 會自行停止。請注意，滯後的 vCPU 的進度明顯低於最快的同級 vCPU，而領先的 vCPU 是比最慢的同級 vCPU 取得更大進步的 vCPU。通過跟踪最慢的同級 vCPU，每個 vCPU 現在可以獨立做出自己的協同調度決策。與共同停止一樣，共同啟動決定也是單獨做出的。一旦最慢的同級 vCPU 開始執行，共同停止的 vCPU 就有資格共同啟動，並且可以根據 pCPU 的可用性進行調度。這解決了嚴格協同調度算法中的 CPU 碎片問題，不需要將一組 vCPU 一起調度。在前面的 4-vCPU 虛擬機範例中，即使只有一個空閒 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。通過跟踪最慢的同級 vCPU，每個 vCPU 現在可以獨立做出自己的協同調度決策。與共同停止一樣，共同啟動決定也是單獨做出的。一旦最慢的同級 vCPU 開始執行，共同停止的 vCPU 就有資格共同啟動，並且可以根據 pCPU 的可用性進行調度。這解決了嚴格協同調度算法中的 CPU 碎片問題，不需要將一組 vCPU 一起調度。在前面的 4-vCPU 虛擬機範例中，即使只有一個空閒 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。通過跟踪最慢的同級 vCPU，每個 vCPU 現在可以獨立做出自己的協同調度決策。與共同停止一樣，共同啟動決定也是單獨做出的。一旦最慢的同級 vCPU 開始執行，共同停止的 vCPU 就有資格共同啟動，並且可以根據 pCPU 的可用性進行調度。這解決了嚴格協同調度算法中的 CPU 碎片問題，不需要將一組 vCPU 一起調度。在前面的 4-vCPU 虛擬機範例中，即使只有一個空閒 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。一旦最慢的同級 vCPU 開始執行，共同停止的 vCPU 就有資格共同啟動，並且可以根據 pCPU 的可用性進行調度。這解決了嚴格協同調度算法中的 CPU 碎片問題，不需要將一組 vCPU 一起調度。在前面的 4-vCPU 虛擬機範例中，即使只有一個空閒 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。一旦最慢的同級 vCPU 開始執行，共同停止的 vCPU 就有資格共同啟動，並且可以根據 pCPU 的可用性進行調度。這解決了嚴格協同調度算法中的 CPU 碎片問題，不需要將一組 vCPU 一起調度。在前面的 4-vCPU 虛擬機範例中，即使只有一個空閒 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。即使只有一個空閒的 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。即使只有一個空閒的 pCPU 可用，虛擬機也可以繼續前進。這顯著提高了 CPU 使用率。
上面的片段來自 VMware 自己的文件。
因此 VMware 不再使用嚴格的 gang 調度。我會將直接來自供應商的文件視為更具權威性。
唯一能給你提供硬數據的是基準測試，它完全取決於 CPU 執行的程式碼類型。但我可以告訴你，如果 VMware 處於這樣的劣勢，那麼他們就不會在虛擬化市場上佔據最大份額。