Es casi un hecho diario encontrar parches interesantes para el kernel de Linux (¡y también para otros proyectos de código abierto!) por parte de la gran camarilla de ingenieros de código abierto de Intel. Lo último que cruzó mi radar es permitir que el controlador”intel_idle”de Linux se ejecute dentro de los invitados de la máquina virtual (VM).
El destacado ingeniero de Intel Linux, Arjan van de Ven, ha publicado un conjunto de parches para permitir la compatibilidad con el controlador intel_idle para máquinas virtuales. Estos parches, junto con los próximos parches de compatibilidad con C0.2, deberían proporcionar un buen aumento de rendimiento para las máquinas virtuales, especialmente en aquellas que soportan un uso intensivo de E/S.
Arjan explicó con los parches:
intel_idle proporciona los estados de inactividad de la CPU (para ahorrar energía en inactividad) al marco cpuidle, en función de las tablas por CPU combinadas con una enumeración de hardware limitada. Esta combinación de cpuidle e intel_idle proporciona un comportamiento dinámico en el que el ahorro de energía y el impacto en el rendimiento se equilibran dinámicamente y en el que se proporciona un conjunto de perillas genéricas en sysfs para que los usuarios ajusten la heurística (y obtengan estadísticas, etc.)
Sin embargo, intel_idle actualmente no admite la ejecución dentro de los invitados de VM, y el kernel de Linux recurre a la inactividad basada en ACPI (si es compatible con el hipervisor/bios virtual) o simplemente al método inactivo basado en”hlt”de respaldo x86 predeterminado… que se introdujo en la serie de kernel 1.2… y carece de todo el comportamiento dinámico, el control del usuario y las estadísticas que trae cpuidle.
Si bien esto es obviamente funcional, no es genial y podemos hacerlo mejor para el usuario conectando intel_idle en el marco cpuidle también para el caso”en un invitado”. Y no solo no es bueno para el usuario, tampoco es óptimo y carece de dos capacidades clave que son compatibles con la carcasa de metal:
1) La capacidad de vaciar el TLB durante períodos de inactividad muy prolongados, para evitar una reactivación IPI costosa (y de alta latencia) posterior, de una vCPU inactiva cuando un proceso que solía ejecutarse en la vCPU inactiva realiza un munmap o una operación similar. Evitar los IPI de alta latencia ayuda a evitar la fluctuación del rendimiento.
2) La capacidad de usar el nuevo estado de inactividad de Intel C0.2 en lugar de sondear durante períodos de inactividad de muy corta duración para ahorrar energía (y huella de carbono)Esta serie de parches agrega el soporte básico para ejecutar en un invitado de VM al controlador intel_idle y luego aborda la primera de estas deficiencias. La brecha de C0.2 se solucionará con un pequeño parche adicional después de que el soporte de C0.2 se fusione por separado.
Excelente trabajo y será interesante probarlo una vez que los parches de soporte de C0.2 estén listos. también listo para beneficiarse de los últimos servidores Intel Xeon Scalable.
