LinuxParty

La administración de energía en el hipervisor de proyectos Xen se dirige históricamente a las aplicaciones de servidor para mejorar el consumo de energía y la administración de calor en los centros de datos, lo que reduce los costos de electricidad y refrigeración. En el espacio integrado, el Xen Project Hypervisor enfrenta aplicaciones, arquitecturas y requisitos de potencia muy diferentes, que se centran en la duración de la batería, el calor y el tamaño.

Aunque se aplican los mismos principios fundamentales de administración de energía, la infraestructura de administración de energía en el Xen Project Hypervisor requiere nuevas interfaces, métodos y políticas adaptadas a arquitecturas y aplicaciones integradas. Esta publicación recapitula la administración de energía del proyecto Xen, cómo cambian los requisitos en el espacio integrado y cómo este cambio puede unir las funciones del hipervisor y del administrador de energía.

Evolución de Xen Project Power Management en x86

El tiempo compartido de los recursos de la computadora por diferentes máquinas virtuales (VM) fue el precursor de la programación y la virtualización. Compartir el tiempo utilizando las estimaciones de la carga de trabajo era un proxy bueno y bastante simple para compartir la energía. Como en todos los sistemas operativos principales, la administración de energía y energía en el Xen Project Hypervisor llegó como una ocurrencia tardía.

Intel y AMD desarrollaron las primeras formas de administración de energía para el Proyecto Xen con la arquitectura x86_64. Inicialmente, el proyecto Xen utilizó la instrucción `hlt 'para la CPU al ralentí y no tenía ningún soporte para estados de reposo más profundos. Luego, se presentó el soporte para suspender a RAM, también conocido como ACPI S3. Fue completamente impulsado por Dom0 y fue diseñado para soportar suspensiones manuales de la máquina por parte del usuario, por ejemplo, cuando la tapa está cerrada en una computadora portátil. No fue diseñado para reducir la utilización de energía en circunstancias normales. Como resultado, el ahorro de energía fue mínimo y se limitó a los efectos de `hlt '.

Finalmente, Intel presentó soporte para cpu-freq en el Proyecto Xen en 2007. Esta fue la primera forma no trivial de administración de energía para el Proyecto Xen. Cpu-freq disminuye la frecuencia de la CPU en tiempo de ejecución para reducir el consumo de energía cuando la CPU se utiliza de forma ligera. Una vez más, cpu-freq fue totalmente manejado por Dom0: el hipervisor permitió a Dom0 controlar la frecuencia de las CPU físicas subyacentes.

No solo fue un enfoque retrógrado desde el punto de vista de la arquitectura Xen, sino que este enfoque fue severamente limitante. Dom0 no tenía una vista completa del sistema para tomar las decisiones correctas. Además, requería una CPU virtual en Dom0 para cada CPU física y fijar cada CPU virtual Dom0 a una CPU física diferente. No era una opción viable a largo plazo.

Para resolver este problema, cpu-freq fue rediseñado, moviendo el controlador cpu-freq al hipervisor. Por lo tanto, Xen Project fue capaz de cambiar la frecuencia de la CPU y tomar decisiones de ahorro de energía por sí mismo, resolviendo estos problemas.

Intel y AMD introdujeron el soporte para estados de suspensión profunda casi al mismo tiempo que el rediseño de cpu-freq. El Xen Project Hypervisor agregó la capacidad de inactivar CPUs físicas más allá de la simple instrucción 'hlt'. Los estados de reposo más profundo, también conocidos como estados C de ACPI, tienen mejores propiedades de ahorro de energía, pero tienen un costo de latencia más alto. Cuanto más profundo es el estado de reposo, más energía se ahorra, más tiempo lleva reanudar el funcionamiento normal. La decisión de entrar en un estado de sueño se basa en dos variables: tiempo y energía. Sin embargo, la programación y la marcha en vacío siguen siendo actividades separadas por grandes márgenes. Como ejemplo, el planificador tiene una influencia muy limitada en la elección del estado de sueño particular.

Xen Project Power Management en el brazo

La primera versión de Xen con soporte Arm fue Xen 4.3 en 2013, pero la administración de energía de Xen no se ha abordado activamente hasta hace muy poco. Una de las razones puede ser el dominio de los hipervisores propietarios y internos para Arm en el espacio integrado y la prevalencia abrumadora de x86 para servidores. Debido a la madurez del Proyecto Xen, su modelo de código abierto y su amplia implementación, se utiliza con frecuencia en la actualidad en una variedad de aplicaciones basadas en Arm. El soporte de administración de energía para el hipervisor de Xen Project en Arm se está volviendo esencial, en particular en el mundo integrado.

En nuestra próxima publicación de blog, abordaremos las opciones arquitectónicas de Xen on Arm en el mundo integrado y utilizaremos casos sobre cómo hacer que esto funcione.

Xen Power Management para aplicaciones integradas

Las aplicaciones integradas requieren las mismas capacidades de aislamiento y seguridad del sistema operativo que motivaron el desarrollo de la virtualización de servidores, pero vienen con una variedad más amplia de arquitecturas multinúcleo, sistemas operativos invitados y asignaciones de hardware virtual a físico. Además, la mayoría de los diseños integrados son muy sensibles a los deterioros en el rendimiento, el tamaño de la memoria, la eficiencia energética y la latencia de activación que a menudo vienen con hipervisores. Como los dispositivos integrados son cada vez más fríos, más silenciosos, más pequeños y funcionan con baterías, la administración eficiente de la energía se presenta como un obstáculo vital para la adopción exitosa de hipervisores en la comunidad integrada.

Los dispositivos integrados estándar no virtualizados administran la energía en dos niveles: la plataforma y el nivel del sistema operativo. En el nivel de la plataforma, el administrador de la plataforma se ejecuta típicamente en procesadores y microcontroladores dedicados en el chip o en la placa. Está monitoreando y controlando el consumo de energía de las CPU, los periféricos, los grupos de CPU y todos los componentes de nivel de placa al cambiar las frecuencias, los voltajes y los estados funcionales del hardware. Sin embargo, no tiene ningún conocimiento intrínseco sobre las aplicaciones en ejecución, lo cual es necesario para tomar las decisiones correctas para ahorrar energía.

Este conocimiento es proporcionado por el sistema operativo o, en algunos casos, directamente por el software de la aplicación en sí. La interfaz de coordinación de estado de alimentación (PSCI) y la interfaz de administración de energía extensible (EEMI) se utilizan para coordinar los eventos de alimentación entre el administrador de plataforma, los SO y los clústeres de procesamiento. Mientras que PSCI coordina los eventos de potencia entre las CPU de un solo clúster de procesador, EEMI es responsable de los periféricos y la interacción de potencia entre múltiples clústeres.

Contrariamente a la administración de energía basada en ACPI para las arquitecturas x86 típicas de los escritorios y servidores, PSCI y EEMI permiten un control mucho más directo y permiten una administración de energía precisa de los clústeres virtuales. En los sistemas integrados, cada microjulio cuenta, por lo que la precisión en términos de tiempo y alcance de las acciones de administración de energía es esencial.

Cuando se inserta una capa de virtualización entre los sistemas operativos y el administrador de la plataforma, se habilitan de manera efectiva clústeres virtuales adicionales, que vienen con CPU virtuales, periféricos virtuales e incluso periféricos físicos con paso a través del dispositivo. La coordinación de poder EEMI de los clústeres virtuales se puede ejecutar en el administrador de la plataforma, el hipervisor o ambos. Si se selecciona el administrador de la plataforma, la administración de energía puede hacerse muy precisa, pero a expensas de la distensión de la memoria del firmware, ya que necesita administrar no solo los clústeres físicos fijos sino también los clústeres virtuales creados dinámicamente.

Además, el administrador de la plataforma requiere capacidades de procesamiento más sólidas para administrar la energía de manera óptima, especialmente si se toman en consideración las cargas del clúster y del sistema. Como los administradores de la plataforma suelen residir en dominios de baja potencia, escasean tanto el espacio de memoria como la capacidad de procesamiento.

El hipervisor generalmente se ejecuta en potentes clusters de CPU, por lo que tiene suficiente memoria y capacidad de procesamiento a su disposición. También está bien informado sobre la partición y la carga de los clústeres virtuales, lo que lo convierte en el lugar ideal para administrar la energía. Sin embargo, para una administración de energía adecuada, el hipervisor también requiere un modelo de energía precisa de los clústeres físicos subyacentes. De manera similar al programador de energía en Linux, el hipervisor debe unir el tiempo y la energía compartidos para administrar la energía adecuadamente. En este caso, la administración de energía basada en el sistema operativo se transforma de manera efectiva en la administración de energía basada en hipervisor. El hipervisor y el administrador de potencia se fusionan

La mayoría de los diseños integrados consisten en múltiples clústeres o subsistemas físicos que con frecuencia se ponen en estados de baja energía inactivos para ahorrar energía, como suspender, suspender, hibernar o suspender el apagado. Ejemplos típicos son la aplicación, el video en tiempo real o los clústeres de aceleradores que poseen múltiples CPU y comparten la memoria del sistema, los periféricos, los componentes del nivel de la placa y la fuente de energía. Si todos los clústeres entran en estados de bajo consumo de energía, sus hipervisores respectivos están inactivos, y el administrador de la plataforma siempre activo debe asumir la responsabilidad exclusiva de la administración de energía del sistema. Una vez que los clústeres vuelven a estar activos, la administración de energía se transfiere a los hipervisores respectivos. Con el fin de asegurar una administración de energía óptima, los hipervisores y el administrador de energía deben actuar como uno, finalmente fusionándose en un software de sistema distribuido que cubra tanto el rendimiento como la administración de energía.

Un buen ejemplo de un diseño en acción que indica dicha evolución es el soporte de administración de energía para Xilinx Zynq UltraScale + MPSoC. El hipervisor Xen que se ejecuta en la Unidad de Procesamiento de Aplicaciones (APU) y el administrador de energía en la Unidad de Administración de Energía (PMU) ya se han convertido en un conjunto compacto alrededor de la administración de energía basada en EEMI y evolucionarán con el próximo soporte de reloj EEMI.

El próximo blog de esta serie cubrirá la función de suspender a RAM para el Xen Project Hypervisor dirigido a Xilinx Zynq UltraScale + MPSoC, que sienta las bases para una administración de potencia a escala completa en las arquitecturas de Arm.

Autores:

Vojin Zivojnovic, CEO y cofundador de AGGIOS

Stefano Stabellini, Ingeniero Principal en Xilinx y Xen Project Maintainer