Los desarrolladores de Canonical, dieron a conocer mediante una lista de correo del desarrollo del kernel de Linux, un conjunto de parches para la implementación de la limpieza de memoria oportunista, que tiene como objetivo el reducir significativamente el tiempo en modo de suspensión del sistema.

La optimización se logra mediante la invocación proactiva de la liberación de estructuras de memoria secundarias que no contienen información única y que pueden restaurarse dinámicamente después de regresar del modo de suspensión (por ejemplo, áreas de memoria anónimas y varias memorias caché de páginas de memoria).

Sobre los parches

La idea principal es que después de eliminar datos innecesarios, el tamaño de la imagen de memoria se reduce para guardar antes de pasar al modo de suspensión y en consecuencia, se requiere menos tiempo para escribir y leer desde un medio lento.

Por defecto, al guardar un volcado de memoria para el modo de suspensión, el núcleo guarda la memoria como está con todas las cachés, pero existe una posibilidad estándar de liberar estructuras innecesarias simulando condiciones de recursos insuficientes en la etapa inicial de transición al modo de suspensión.

Esta característica se puede activar usando el parámetro «/sys/power/image_size» y conduce a una reducción notable en el tiempo para pasar al modo de suspensión.

Canonical sugiere agregar dos parámetros más, que permitirán la liberación de estructuras innecesarias por adelantado para que la transición real al modo de suspensión se complete lo más rápido posible y regresar del modo de suspensión tomó aproximadamente la misma cantidad de tiempo que cuando se aplica el parámetro.

Pruebas y resultados

Las pruebas en un sistema con 8 GB de RAM y una partición de intercambio de 8 GB mientras se utiliza el 85% de la memoria mostraron en la configuración predeterminada (image_size = default) una disminución en el tiempo para pasar al modo de suspensión de 51.56 a 4.19 segundos cuando el proceso de limpieza del exceso de memoria se inició 60 segundos antes de cambiar a modo de suspencion.

Debido a la reducción en el tamaño de la imagen de memoria guardada, el tiempo de recuperación disminuyó de 26.34 a 5 segundos.

Aquí está el primer intento de proporcionar una interfaz que permita que las tareas de espacio de usuario activen una recuperación de memoria oportunista antes de hibernar un sistema.

Recuperar la memoria por adelantado (p. Ej., Cuando el sistema está inactivo) permite
reducir el tamaño de la imagen de hibernación y acelerar significativamente el tiempo de hibernación y reanudación.

Cuando el modo de limpieza normal para el exceso de memoria (image_size = 0) estaba habilitado en el sistema, el tiempo para pasar al modo de suspensión disminuyó de 73.22 a 5.36 segundos y el tiempo para regresar del modo de suspensión no cambió (disminuyó solo por una fracción de segundo, de 5.32 a 5.26 segundos).

El caso de uso típico de esta característica es permitir que las instancias en la nube de alta prioridad se adelanten a las instancias de baja prioridad (por ejemplo, instancias «spot» [1]) hibernándolas.

La recuperación de memoria oportunista es muy efectiva para hibernar rápidamente instancias que asignan una gran cantidad de memoria y permanecen en su mayor parte inactivas la mayor parte del tiempo, solo usando un conjunto de trabajo mínimo.

Uso

El método propuesto puede ser solicitado en situaciones en las que es necesario pasar rápidamente al modo de suspensión y es posible anticipar la necesidad de tal transición por adelantado.

Por ejemplo, en sistemas en la nube, entornos virtuales de baja prioridad (entornos puntuales en Amazon EC2) se puede entrar dinámicamente en hibernación y liberar memoria ocupada a medida que crece el consumo de recursos primarios.

Cuando se reduce la carga en los entornos primarios, los entornos de baja prioridad regresan del modo de suspensión. En estas condiciones, para mantener la calidad de servicio adecuada, es importante minimizar el tiempo para pasar al modo de suspensión y salir de él.

La fase de limpieza preventiva puede iniciarse cuando se alcanza un cierto nivel de la carga principal, que precede al nivel que conduce a la congelación de entornos de baja prioridad.

Fuente: https://lkml.org