Compression de mémoire virtuelle

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].

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.

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].

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.

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.

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é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].