Compresión de memoria virtual

Uno de los problemas principales es el grado en que el contenido de la memoria física puede comprimirse bajo cargas reales. El código del programa y gran parte de los datos almacenados en la memoria física a menudo no son altamente compresibles, ya que las técnicas de programación eficientes y las arquitecturas de datos están diseñadas para eliminar automáticamente la redundancia en los conjuntos de datos. Varios estudios muestran índices de compresión de datos típicos que van de 2:1 a 2,5:1 para los datos del programa, ^{[ 7 ] [ 11 ]} similares a los índices de compresión que se suelen lograr con la compresión de disco . ^{[ 10 ]}

Para que la compresión de memoria virtual proporcione mejoras de rendimiento medibles, el rendimiento del sistema de memoria virtual debe mejorarse en comparación con su equivalente sin comprimir. Por lo tanto, la cantidad adicional de procesamiento introducida por la compresión no debe aumentar la latencia general. Sin embargo, en sistemas con limitaciones de E/S o aplicaciones con conjuntos de datos altamente compresibles, las ganancias pueden ser sustanciales. ^{[ 10 ]}

La memoria física utilizada por un sistema de compresión reduce la cantidad de memoria física disponible para los procesos que ejecuta el sistema, lo que puede provocar un aumento de la actividad de paginación y una menor eficacia general de la compresión de la memoria virtual. Esta relación entre la actividad de paginación y la memoria física disponible es aproximadamente exponencial, lo que significa que reducir la cantidad de memoria física disponible para los procesos del sistema produce un aumento exponencial de la actividad de paginación. ^{[ 12 ] [ 13 ]}

En circunstancias donde la cantidad de memoria física libre es baja y la paginación es bastante frecuente, cualquier mejora de rendimiento que proporcione el sistema de compresión (en comparación con la paginación directa hacia y desde el almacenamiento auxiliar) puede verse contrarrestada por un aumento en la tasa de fallos de página que provoca sobrecarga y degradación del rendimiento del sistema. En el caso opuesto, donde hay suficiente memoria física disponible y la actividad de paginación es baja, la compresión puede no tener un impacto significativo en el rendimiento. El punto intermedio entre estas dos circunstancias —pocaRAM con alta actividad de paginación y mucha RAM con baja actividad de paginación— esdonde la compresión de memoria virtual puede ser más útil. Sin embargo, cuanto más compresibles sean los datos del programa, más pronunciadas serán las mejoras de rendimiento, ya que se necesita menos memoria física para almacenar los datos comprimidos.

Por ejemplo, para maximizar el uso de una caché de páginas comprimidas, Hurricane 2.0 de Helix Software Company  proporciona un umbral de rechazo de compresión configurable por el usuario. Al comprimir los primeros 256 a 512 bytes de una  página de 4 KiB, este sistema de compresión de memoria virtual determina si se puede alcanzar el umbral de nivel de compresión configurado para una página en particular; si es posible, el resto de la página se comprimiría y se conservaría en una caché comprimida, y de lo contrario, la página se enviaría al almacenamiento auxiliar a través del sistema de paginación normal. La configuración predeterminada para este umbral es una relación de compresión de 8:1. ^{[ 14 ] [ 4 ]}

En las implementaciones de hardware, la tecnología también se basa en las diferencias de precio entre los distintos componentes del sistema; por ejemplo, la diferencia entre el coste de la memoria RAM y el de un procesador dedicado a la compresión. La relación precio-rendimiento de los distintos componentes tiende a variar con el tiempo. Por ejemplo, la incorporación de un coprocesador de compresión puede tener un impacto mínimo en el coste de la CPU.

En una implementación típica de memoria virtual, la paginación se realiza según el uso menos reciente , lo que puede provocar que el algoritmo de compresión consuma ciclos de CPU al procesar los datos de menor prioridad. Además, el código del programa suele ser de solo lectura y, por lo tanto, nunca se pagina. En su lugar, el código simplemente se descarta y se vuelve a cargar desde el archivo de almacenamiento auxiliar del programa si es necesario. En este caso, el umbral de compresión es más alto, ya que el ciclo de E/S que se intenta eliminar es mucho más corto, especialmente en dispositivos de memoria flash.

La variante Unix de Acorn Computers , RISC iX , se suministró como sistema operativo principal para su estación de trabajo R140 lanzada en 1989. ^{[ 15 ]} RISC iX proporcionaba soporte para la paginación bajo demanda de archivos ejecutables comprimidos. Sin embargo, la principal motivación para proporcionar archivos ejecutables comprimidos era alojar un sistema Unix completo en un disco duro de tamaño relativamente modesto. Los datos comprimidos no se paginaban al disco bajo este esquema. ^{[ 16 ] [ 17 ]}

Paul R. Wilson propuso el almacenamiento en caché comprimido de páginas de memoria virtual en 1990, en un documento distribuido en el taller ACM OOPSLA/ECOOP '90 sobre recolección de basura ("Algunos problemas y estrategias en la administración de montones y jerarquías de memoria"), y que apareció en ACM SIGPLAN Notices en enero de 1991. ^{[ 18 ]}

Helix Software Company fue pionera en la compresión de memoria virtual en 1992, presentando una solicitud de patente para el proceso en octubre de ese año. ^{[ 2 ]} En 1994 y 1995, Helix perfeccionó el proceso utilizando compresión de prueba y cachés de memoria secundaria en tarjetas de video y otros dispositivos. ^{[ 3 ]} Sin embargo, Helix no lanzó un producto que incorporara compresión de memoria virtual hasta julio de 1996 con el lanzamiento de Hurricane  2.0, que utilizaba el algoritmo de compresión Lempel-Ziv-Stac de Stac Electronics y también utilizaba RAM de video fuera de pantalla como búfer de compresión para obtener beneficios de rendimiento. ^{[ 14 ]}

En 1995, la RAM costaba casi 50 dólares por megabyte , y Windows 95 de Microsoft indicaba un requisito mínimo de 4 MB de RAM. ^{[ 19 ]} Debido al alto requisito de RAM, se lanzaron varios programas que afirmaban utilizar tecnología de compresión para obtener “memoria”. El más notorio fue el programa SoftRAM de Syncronys Softcorp. SoftRAM fue desenmascarado como falso porque no realizaba ninguna compresión. ^{[ 20 ] [ 10 ]} Otros productos, incluidos Hurricane y MagnaRAM , incluían compresión de memoria virtual, pero solo implementaban codificación de longitud de ejecución , con resultados deficientes, lo que le dio a la tecnología una reputación negativa. ^{[ 21 ]} 

En su edición del 8 de abril de 1997, PC Magazine publicó una prueba exhaustiva de las afirmaciones de mejora del rendimiento de varias herramientas de compresión de memoria virtual de software. En sus pruebas, PC Magazine encontró una mejora mínima (5% en general) del rendimiento con el uso de Hurricane, y ninguna en absoluto con ninguno de los otros paquetes. ^{[ 21 ]} Sin embargo, las pruebas se realizaron en sistemas Intel Pentium que tenían un solo núcleo y eran de un solo hilo, por lo que la compresión impactó directamente en toda la actividad del sistema.

En 1996, IBM comenzó a experimentar con la compresión, y en 2000 anunció su tecnología Memory eXpansion Technology (MXT). ^{[ 22 ] [ 23 ]} MXT era un chip independiente que actuaba como caché de CPU entre la CPU y el controlador de memoria. MXT tenía un motor de compresión integrado que comprimía todos los datos que entraban y salían de la memoria física. Las pruebas posteriores de la tecnología realizadas por Intel mostraron una mejora del rendimiento general del sistema de entre el 5 % y el 20 %, similar a los resultados obtenidos por PC Magazine con Hurricane. ^{[ 24 ]}

• A principios de 2008, se lanzó un proyecto de Linux llamado zram (originalmente llamado compcache); en una actualización de 2013, se incorporó a ChromeOS ^{[ 25 ]} y Android 4.4
• En 2010, IBM lanzó Active Memory Expansion (AME) para AIX 6.1, que implementa la compresión de memoria virtual. ^{[ 26 ]}
• En 2012, algunas versiones del chip POWER7 + incluían aceleradores de hardware AME que utilizaban el algoritmo de compresión 842 para la compresión de datos, utilizado en AIX, para la compresión de memoria virtual. ^{[ 27 ]} Los procesadores POWER más recientes siguen siendo compatibles con esta función.
• En diciembre de 2012 se anunció el proyecto zswap , que se integró en la rama principal del kernel de Linux en septiembre de 2013.
• En junio de 2013, Apple anunció que incluiría compresión de memoria virtual en OS X Mavericks , utilizando el algoritmo Wilson-Kaplan WKdm. ^{[ 28 ] [ 29 ]}
• Una actualización del 10 de agosto de 2015 de " Windows Insider Preview" para Windows 10 (compilación 10525) agregó soporte para compresión de RAM. ^{[ 30 ]}