Compression de mémoire virtuelle

La compression de mémoire virtuelle (en anglais, virtual memory compression, RAM compression ou memory compression) est une technique de gestion de mémoire virtuelle qui utilise la compression de données pour réduire la taille ou le nombre de requêtes de pagination vers et depuis le stockage auxiliaire.

Dans un système de compression de mémoire virtuelle, les pages sont compressées et stockées dans la mémoire physique, généralement une mémoire RAM, ou envoyées compressées vers un stockage auxiliaire, tel qu'un disque dur ou un disque SSD. Dans les deux cas, la plage de mémoire virtuelle dont le contenu a été compressé est inaccessible, de sorte que les tentatives d'accès aux pages compressées déclenchent des erreurs de page et inversent le processus de compression (récupération des informations et décompression). L'empreinte des données paginées est réduite par le processus de compression et la mémoire RAM libérée est renvoyée dans le pool de mémoire physique disponible. Dans le cas où les pages compressées sont conservées dans la mémoire RAM, les pages compressées utilisent évidemment moins d'espace que les pages originales. Dans le cas où les pages compressées sont conservées dans un stockage auxiliaire, la mémoire RAM est complètement libérée et les opérations d'écriture et de lecture sur la mémoire auxiliaire sont plus rapides que si les pages n'avaient pas été compressées^[1]^,^[2].

Dans certaines implémentations, incluant zswap (en), zRam et Helix de Hurricane Software Company, l'ensemble du processus est implémenté au moyen de logiciel. Dans d'autres systèmes, tels que MXT d'IBM, le processus se fait dans un processeur dédié qui gère les transferts entre un cache local et la mémoire RAM.

En réduisant les activités d'entrée / sortie causées par les demandes de pagination, la compression de la mémoire virtuelle peut entraîner des améliorations globales de performances. Le degré d'amélioration de performances dépend de divers facteurs, notamment la disponibilité de co-processeurs de compression, la bande passante disponible sur le processeur, la vitesse du canal d'entrée-sortie, la vitesse de la mémoire physique et la compressibilité du contenu de la mémoire.

Sur les processeurs multicore et multithread, certains benchmarks montrent des améliorations de performances de plus de 50 %^[3]^,^[4].

Dans certaines situations, comme dans les systèmes embarqués, le stockage auxiliaire est limité ou inexistant. Dans ces cas, la compression de la mémoire virtuelle peut permettre à un système de mémoire virtuelle de fonctionner, alors que la mémoire virtuelle devrait sinon être désactivée. Cela permet au système d'exécuter certains logiciels qui seraient autrement incapables de fonctionner dans un environnement sans mémoire virtuelle.

La mémoire flash a certaines limites d'endurance relativement au nombre maximum de cycles d'effacement qu'elle peut subir, qui peut être aussi bas que 100 cycles d'effacement. Dans les systèmes où la mémoire flash est utilisée comme seul système de stockage auxiliaire, la mise en œuvre de la compression de la mémoire virtuelle peut réduire la quantité totale de données écrites dans le stockage auxiliaire, améliorant ainsi la durée de vie du système.

Faiblesses

Faible taux de compression

L'un des principaux problèmes de la compression de mémoire virtuelle est le degré auquel le contenu de la mémoire vive peut être compressé sous des charges réelles. Le code de programme et la plupart des données contenues dans la mémoire ne sont souvent pas très compressibles, car des techniques de programmation et des architectures de données efficaces sont conçues pour éliminer automatiquement la redondance dans les ensembles de données. Diverses études montrent des taux de compression de données typiques varient de 2 : 1 à 2,5 : 1 pour les données de programme^[5]^,^[6].

Entrées-sorties en arrière-plan

Pour que la compression de mémoire virtuelle fournisse des améliorations de performance mesurables, le débit du système de mémoire virtuelle doit être amélioré par rapport à l'équivalent non compressé. Ainsi, la quantité supplémentaire de traitement introduite par la compression ne doit pas augmenter la latence globale. Cependant, dans les systèmes où la performance est tributaire des entrées-sorties (I/O bound) ou dans les applications avec des données hautement compressibles, les gains peuvent être substantiels.

Augmentation du thrasing

La mémoire physique utilisée par un système de compression réduit la quantité de mémoire physique disponible pour les processus qu'un système exécute, ce qui peut entraîner une augmentation de l'activité de pagination et une réduction de l'efficacité globale de la compression de la mémoire virtuelle. Cette relation entre l'activité de pagination et la mémoire physique disponible peut être à peu près exponentielle, ce qui signifie que la réduction de la quantité de mémoire physique disponible pour les processus système peut entraîner une augmentation exponentielle de l'activité de pagination^[7]^,^[8].

Dans les cas où la quantité de mémoire physique libre est faible et la pagination est assez importante, tous les gains de performances fournis par le système de compression (comparés à la pagination directe vers et depuis le stockage auxiliaire) peuvent être annulés par un taux d'erreurs de page accru, ce qui conduit au thrashing et à une dégradation de la performance du système. Dans les cas inverses, où suffisamment de mémoire physique est disponible et l'activité de pagination est faible, la compression peut ne pas avoir d'impact sur la performance. Le point médian entre ces deux situations - faible RAM avec une activité de pagination élevée, et beaucoup de RAM avec une faible activité de pagination - est l'endroit où la compression de la mémoire virtuelle peut être la plus utile. De plus, plus les données du programme sont compressibles, plus les améliorations de performance sont prononcées, car moins de mémoire physique est nécessaire pour contenir les données compressées.

Par exemple, afin de maximiser l'utilisation d'un cache de pages compressées, Hurricane 2.0 de Helix Software Company fournit un seuil de rejet de compression configurable par l'utilisateur. En comprimant les premiers 256 à 512 octets d'une page de 4 ko, ce système de compression de mémoire virtuelle détermine si le seuil de compression configuré peut être atteint pour une page particulière. Si le seuil peut être atteint, le reste de la page est compressé et conservé dans un cache compressé, sinon la page est envoyée au stockage auxiliaire via le système de pagination normal. Le paramètre par défaut pour ce seuil est un taux de compression de 8 : 1^[9]^,^[10].

Relation prix / performance

Dans les implémentations matérielles, la technologie repose également sur les différentiels de prix entre les différents composants du système, par exemple, la différence entre le coût de la mémoire RAM et le coût d'un coprocesseur dédié à la compression. Les différences de prix / performances relatives des différents composants ont tendance à varier dans le temps. Par exemple, dans les ordinateurs modernes, l'ajout d'un coprocesseur de compression peut avoir un impact minimal sur le coût du processeur.

Priorisation

Dans une implémentation de mémoire virtuelle typique, la pagination se produit sur la page qui n'a pas été utilisée depuis le plus longtemps, ce qui peut provoquer l'utilisation par l'algorithme de compression de cycles de processeur traitant les données de priorité la plus faible. En outre, le code du programme est généralement en lecture seule, et n'est donc jamais copié sur disque par pagination. Au lieu de cela, le code du programme est simplement écrasé par une nouvelle page et rechargé à partir du fichier de stockage auxiliaire si nécessaire. Dans ce cas, la barre de compression est plus élevée, car le cycle d'entrée-sortie qu'il tente d'éliminer est beaucoup plus court, en particulier sur les dispositifs de mémoire flash.

Histoire

La compression de la mémoire virtuelle est une technologie dont la popularité a fluctué dans le temps. Le prix et la vitesse de la mémoire RAM et du stockage externe ont évolué rapidement en raison de la loi de Moore et des améliorations aux interfaces de la mémoire RAM telles que DDR3, réduisant ainsi le besoin de compression de la mémoire virtuelle. Par contre, les processeurs multi-cœur, les fermes de serveurs et la technologie mobile combinés à l'avènement de systèmes basés sur la mémoire flash ont rendu la compression de la mémoire virtuelle plus attrayante.

Origine

Paul R. Wilson a proposé une mise en cache compressée des pages de mémoire virtuelle en 1990, dans un document sur le garbage collection diffusé lors de l'ACM OOPSLA / ECOOP '90 Workshop (Some Issues and Strategies in Heap Management and Memory Hierarchies ; en français, Quelques problèmes et stratégies dans la gestion des piles et de la mémoire) et publié dans les ACM SIGPLAN Noticles en janvier 1991.

Helix Software Company (en) a été le pionnier de la compression de mémoire virtuelle en 1992, déposant une demande de brevet pour le processus en octobre de la même année^[1]. En 1994 et 1995, la compagnie a affiné le processus en utilisant des tests de compression (pour voir si ça valait la peine de comprimer certaines données) et des caches de mémoire secondaire sur des cartes vidéos et d'autres dispositifs^[2]. Cependant, Helix n'a pas offert de produits intégrant la compression de mémoire virtuelle avant la sortie de Hurricane 2.0 en juillet 1996. Cette version déployait l'algorithme de compression Stac Electronics Lempel-Ziv-Stac et utilisait la mémoire RAM de la carte vidéo comme tampon de compression pour améliorer les performances^[9].

En 1995, la mémoire RAM coûtait près de 50 $ par mégaoctet et Windows 95 de Microsoft exigeait un minimue de 4 mégaoctets de mémoire RAM^[11]. En raison de cette forte demande en mémoire RAM, plusieurs programmes ont été commercialisés en prétendant utiliser la technologie de compression pour augmenter la capacité de la mémoire. Le programme SoftRAM de Syncronys Softcorp a été l'un des plus connus. SoftRAM s'est avéré être un logiciel placebo qui n'incluait aucune technologie de compression^[12]. D'autres produits, y compris Hurricane et MagnaRAM, implémentaient la compression de la mémoire virtuelle, mais seulement au nieau run-length encoding, avec des résultats médiocres, donnant une mauvaise réputation à la technologie^[13].

Dans son édition du 8 avril 1997, PC Magazine a publié un test complet des promesses d'amélioration de la performance de plusieurs outils de compression de mémoire virtuelle logicielle. Dans ses tests, PC Magazine a constaté une amélioration minime (5 % globalement) avec Hurricane, et aucune amélioration avec les autres logiciels^[13]. Cependant, les tests avaient été exécutés sur des systèmes Intel Pentium qui avaient un seul cœur et étaient mono-thread, et donc la compression affectait directement toute l'activité du système.

En 1996, IBM a commencé à expérimenter la compression et, en 2000, IBM a annoncé sa technologie Memory eXpansion Technology (MXT)^[14]^,^[15]. MXT était une puce autonome qui agissait comme cache de l'unité centrale entre l'unité centrale et le contrôleur de mémoire. MXT avait un moteur de compression intégré qui compressait toutes les données en direction / en provenance de la mémoire physique. Des tests ultérieurs de la technologie par Intel ont montré une amélioration globale de la performance de 5-20%, similaire aux résultats obtenus par le PC Magazine avec Hurricane^[16].

Développements récents

Début 2008, un module du noyau Linux qui augmente la performance d'un ordinateur en comprimant une mémoire virtuelle dans la mémoire vive a été lancé sous le nom de zRam (appelé à l'origine compcache). Dans une mise à jour de 2013, le module a été incorporé dans Chrome OS^[17] et dans Android 4.4.

En 2010, IBM a introduit l'Active Memory Expansion (AME) pour AIX 6.1 qui implémente la compression de la mémoire virtuelle^[18].

En 2012, certaines versions de la puce POWER7+ comprenaient l'accélérateur matériel AME pour la compression de la mémoire virtuelle^[19].

En décembre 2012, le projet zswap (en) a été annoncé. Il a été fusionné dans le noyau Linux principal en septembre 2013.

En juin 2013, Apple a annoncé qu'il inclurait la compression de la mémoire virtuelle dans OS X Mavericks, en utilisant l'algorithme WKdm^[20]^,^[21].

La mise à jour Windows Insider Preview du 10 août 2015 pour Windows 10 (build 10525) a ajouté la prise en charge de la compression de la mémoire virtuelle^[22].