AMD vuelve a mover ficha en el terreno de los servidores. Y lo hace donde realmente importa: en el kernel de Linux. La compañía ha enviado un nuevo conjunto de parches para habilitar una instrucción inédita llamada RMPOPT. No es un detalle menor. Cuando AMD toca el kernel con algo así, normalmente es porque hay silicio nuevo en el horizonte.
Por el momento, RMPOPT no aparece documentado en ningún sitio público más allá de estos parches. Es, literalmente, la primera vez que se oye hablar de esta instrucción. Y si conectamos los puntos —fecha, contexto y roadmap— todo apunta a que podría formar parte de los futuros procesadores AMD EPYC Zen 6 “Venice”, cuyo lanzamiento se espera para finales de este año.
¿Pero qué es exactamente RMPOPT y por qué debería importarte?
Para entenderlo, hay que mirar a la arquitectura SEV-SNP de AMD. En este entorno, tanto el hipervisor como los huéspedes que no son SNP están sometidos a comprobaciones RMP cuando realizan escrituras en memoria. ¿El objetivo? Garantizar la integridad de la memoria de los huéspedes protegidos con SEV-SNP. Seguridad ante todo. Pero claro, esa seguridad tiene un precio: sobrecarga de rendimiento.
Aquí es donde entra RMPOPT. Esta nueva instrucción está diseñada precisamente para reducir esa sobrecarga. ¿Cómo? Permitiendo omitir las comprobaciones RMP en ciertos escenarios muy concretos. En particular, cuando se sabe con certeza que determinadas regiones de memoria de 1 GB no contienen memoria de huéspedes SEV-SNP. Si no hay memoria protegida ahí, no tiene sentido verificarla una y otra vez. Es simple lógica… pero implementada a nivel de arquitectura.
Según describen los propios parches, RMPOPT permite optimizaciones que omiten las comprobaciones RMP cuando se cumple esa condición. Y teniendo en cuenta que SNP está habilitado por defecto, esto significa que actualmente el hipervisor y los huéspedes no SNP están obligados a pasar por esas comprobaciones de escritura sí o sí. Con RMPOPT, ese peaje podría reducirse de forma significativa.
Los cambios no se quedan solo en la instrucción. La serie de parches añade soporte en el kernel de Linux para activar las optimizaciones RMPOPT de forma global sobre toda la RAM del sistema. Además, permite que RMPUPDATE deshabilite esas optimizaciones cuando se inician huéspedes SNP, lo cual mantiene el equilibrio entre rendimiento y seguridad.
También se incorporan nuevas interfaces: una basada en configfs para reactivar las optimizaciones RMP en tiempo de ejecución y otra en debugfs para informar del estado de RMPOPT por CPU en toda la memoria del sistema. Es decir, no solo se activa la función, sino que se da control y visibilidad al administrador. Eso es importante en entornos de servidor reales, donde cada ajuste cuenta.
Curiosamente, los parches no mencionan de forma explícita qué generación de procesadores EPYC incluirá compatibilidad con RMPOPT. El código simplemente comprueba si la función está presente. Sin embargo, el momento elegido para publicar estos cambios no parece casual. Todo encaja con los futuros EPYC “Venice”.
Hay un detalle técnico que refuerza esta sospecha: uno de los parches hace referencia a CPUs numeradas del 0 al 1023. Si tenemos en cuenta que los EPYC Venice apuntan a configuraciones de hasta 256 núcleos y 512 hilos por zócalo, un sistema de doble zócalo de gama alta podría alcanzar precisamente esa escala. No es una confirmación oficial, pero la correlación es difícil de ignorar.
Ahora mismo, este trabajo de habilitación de RMPOPT está en la lista de correo del kernel de Linux, a la espera de revisión e integración. No llegará a la versión 7.0, ya que la ventana de fusión actual está cerrada. Así que lo veremos en una versión posterior. Paciencia.
Fuente: Phoronix
Añadir comentario
Comentarios