¿La programación de pandillas empleada por VMware es un serio inconveniente?

Estaba leyendo algunos artículos de Technet, así como este, sobre las diferencias entre la forma en que VMware e Hyper V hacen la programación de la CPU.

Me preguntaba si podría obtener información objetiva sobre esto. Parece que la programación de pandillas utilizada por VMware es una ENORME desventaja, pero no quiero simplemente tomar el líquido refrigerante. ¿Afecta seriamente el rendimiento o las últimas iteraciones de los hipervisores de VMware resuelven esto?

Editar: cuando digo desventaja, me refiero a la "programación de procesador libre" de Hyper V o, sin embargo, KVM lo hace. El material que estaba leyendo no decía que hubiera problemas con la "programación de procesador libre" que se evita con la programación de pandillas.

Como cantar Bloody Mary en un espejo del baño oscuro, veamos si podemos hacer que Jake Oshins aparezca ...

La programación de pandillas también se conoce como programación conjunta. Creo que VMware prefiere el término programación conjunta a programación de pandillas.

En las versiones ESX anteriores a la versión 3.x, VMware utilizaba una programación "estricta", que tenía los inconvenientes de sincronización. En ESX 3.xy versiones posteriores, VMware cambió a la programación conjunta "relajada".

La programación conjunta relajada reemplazó la programación conjunta estricta en ESX 3.xy se ha refinado en versiones posteriores para lograr una mejor utilización de la CPU y para admitir máquinas virtuales de multiprocesador amplias. La programación conjunta relajada tiene algunas propiedades distintivas en comparación con el estricto algoritmo de programación conjunta. Lo más importante de todo, mientras que en el estricto algoritmo de programación conjunta, la existencia de una vCPU retrasada hace que la máquina virtual completa se detenga conjuntamente. En el algoritmo de coprogramación relajado, una vCPU líder decide si debe detenerse conjuntamente en función del sesgo contra la vCPU hermana más lenta. Si la inclinación es mayor que un umbral, la vCPU principal se detiene por sí sola. Tenga en cuenta que una vCPU retrasada es aquella que progresa significativamente menos que la vCPU hermana más rápida, mientras que una vCPU líder es aquella que progresa significativamente más que la vCPU hermana más lenta. Al rastrear la vCPU hermana más lenta, ahora es posible que cada vCPU tome su propia decisión de programación conjunta de forma independiente. Al igual que co-stop, la decisión de co-inicio también se toma individualmente. Una vez que la vCPU hermana más lenta comienza a progresar, las vCPU co-detenidas son elegibles para reiniciarse y pueden programarse dependiendo de la disponibilidad de pCPU. Esto resuelve el problema de fragmentación de la CPU en el estricto algoritmo de programación conjunta al no requerir que se programe un grupo de vCPU juntas. En el ejemplo anterior de la máquina virtual de 4 vCPU, la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. Al rastrear la vCPU hermana más lenta, ahora es posible que cada vCPU tome su propia decisión de programación conjunta de forma independiente. Al igual que co-stop, la decisión de co-inicio también se toma individualmente. Una vez que la vCPU hermana más lenta comienza a progresar, las vCPU co-detenidas son elegibles para reiniciarse y pueden programarse dependiendo de la disponibilidad de pCPU. Esto resuelve el problema de fragmentación de la CPU en el estricto algoritmo de programación conjunta al no requerir que se programe un grupo de vCPU juntas. En el ejemplo anterior de la máquina virtual de 4 vCPU, la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. Al rastrear la vCPU hermana más lenta, ahora es posible que cada vCPU tome su propia decisión de programación conjunta de forma independiente. Al igual que co-stop, la decisión de co-inicio también se toma individualmente. Una vez que la vCPU hermana más lenta comienza a progresar, las vCPU co-detenidas son elegibles para reiniciarse y pueden programarse dependiendo de la disponibilidad de pCPU. Esto resuelve el problema de fragmentación de la CPU en el estricto algoritmo de programación conjunta al no requerir que se programe un grupo de vCPU juntas. En el ejemplo anterior de la máquina virtual de 4 vCPU, la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. Una vez que la vCPU hermana más lenta comienza a progresar, las vCPU co-detenidas son elegibles para reiniciarse y pueden programarse dependiendo de la disponibilidad de pCPU. Esto resuelve el problema de fragmentación de la CPU en el estricto algoritmo de programación conjunta al no requerir que se programe un grupo de vCPU juntas. En el ejemplo anterior de la máquina virtual de 4 vCPU, la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. Una vez que la vCPU hermana más lenta comienza a progresar, las vCPU co-detenidas son elegibles para reiniciarse y pueden programarse dependiendo de la disponibilidad de pCPU. Esto resuelve el problema de fragmentación de la CPU en el estricto algoritmo de programación conjunta al no requerir que se programe un grupo de vCPU juntas. En el ejemplo anterior de la máquina virtual de 4 vCPU, la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU. la máquina virtual puede avanzar incluso si solo hay una pCPU inactiva disponible. Esto mejora significativamente la utilización de la CPU.

El fragmento anterior es del propio VMware documentación .

Por lo tanto, VMware ya no utiliza una estricta programación de pandillas. Consideraría que la documentación directamente del proveedor es más autorizada.

Lo único que le dará números concretos es un punto de referencia, y dependerá por completo del tipo de código que ejecuten las CPU. Pero puedo decirle que si VMware estuviera en desventaja, entonces todavía no tendrían la mayor parte del mercado de virtualización.

Bien, Ryan, me alegraste el día. No leo este foro tanto como solía hacerlo, pero me registré.

Red888, deberías saber por adelantado que soy un arquitecto de software que trabaja en Hyper-V en Microsoft. Supongo que la mayoría de las personas que leen esto son perfectamente capaces de hacer clic en el enlace de mi nombre debajo de esto y descubrirlo, o incluso buscarme en Google, pero para esta respuesta es útil estar completamente seguro de que las personas que leen esto no tienen dudas sobre mi perspectiva.

En general, la programación de pandillas es útil si el hipervisor no tiene forma de influir en el comportamiento del sistema operativo que se ejecuta dentro de la VM. Esto es, por supuesto, por qué VMware comenzó de esta manera. No poseen ningún sistema operativo, por lo que su objetivo era hacer que los sistemas operativos existentes funcionen bien. Si yo fuera ellos, aquí es donde habría comenzado.

La programación de pandillas, y VMware probablemente diría que tengo razón sobre esto, deja muchas limitaciones sobre cómo puede usar los procesadores físicos dentro de la máquina. El hipervisor a menudo no puede encontrar el recurso adecuado adecuado por el momento. Por lo tanto, han modificado su algoritmo a lo largo de los años, buscando formas de hacer una programación que funcione mejor.

Microsoft (y probablemente varias otras compañías) comenzaron con una visión diferente. Somos dueños de Windows. Haremos que Windows se comporte bien cuando se virtualice. Y así, la programación de pandillas no será necesaria. Ni siquiera nos molestaremos en construir un planificador de pandillas.

Curiosamente, en Microsoft nos importa más que Windows se ejecute bien en comparación con otros sistemas operativos que Hyper-V que se vea mejor que VMware, KVM, Xen, Oracle o Unisys, etc. Así que publicamos las interfaces que Windows utiliza para cooperar con un hipervisor. Aquí tienes un enlace si tienes curiosidad, aunque no lo recomiendo para leer antes de dormir:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Por lo tanto, cualquier proveedor de hipervisor puede exponer las cosas que desencadenarán un comportamiento cooperativo de Windows. Varios de ellos tienen. Sinceramente, no sé si VMware tiene, o tiene, o expondrá esto. Tendrías que preguntarles, o alguien que les preste mucha atención. Y si lo hacen, me sorprendería mucho si no hubieran modificado su agenda para relajarse aún más. Esa última declaración, por supuesto, es pura especulación.

Por lo tanto, mi respuesta final es que dudo que deba tomar una decisión de compra en 2014 en función de cómo funciona el planificador del hipervisor. Sospecho que ya están bastante bien. Hace unos años, eso podría no haber sido cierto.

Debe probar sus cargas de trabajo en los distintos sistemas y ver cómo funcionan. Apuesto a que su rendimiento final se reduce a si su almacenamiento y su red satisfacen sus necesidades.