CRAM Linux est un projet de mémoire compressée pour le système d’exploitation open source créé en 1991 par Linus Torvalds. Présenté par Meta, il s’appuie sur le matériel pour rendre les données directement accessibles en lecture. Son intérêt n’est pas simplement de faire tenir davantage de données en RAM : c’est de réduire le coût de leur récupération, sans suivre le même chemin que ZRAM ou Zswap.
À retenir
Gregory Price, ingénieur chez Meta, a présenté CRAM le 5 octobre 2026 à la Linux Plumbers Conference de Prague. Cette approche utilise une compression matérielle et conserve les pages compressées accessibles en lecture, tandis que les modifications nécessitent leur retour en DRAM classique. Les benchmarks présentés montrent des performances de lecture proches de la DRAM, mais CRAM exige un matériel compatible et n’est pas encore intégré au noyau Linux principal. Ce n’est donc pas une option à activer aujourd’hui sur n’importe quel ordinateur.
Trois mécanismes, pas trois variantes
Linux sait déjà compresser des données en mémoire. Pour comprendre CRAM, il faut cependant distinguer les mécanismes auxquels on le compare.
ZRAM crée un périphérique de stockage compressé dans la RAM. Linux peut notamment l’utiliser comme espace de swap : les pages déplacées vers ce périphérique restent en mémoire physique, mais sous une forme compressée. ZRAM peut également servir à d’autres usages que le swap, comme l’explique la documentation officielle du noyau.
Zswap joue un autre rôle. C’est un cache compressé placé devant un périphérique de swap. Il tente de conserver les pages compressées en RAM pour limiter les accès au stockage ; lorsque son cache atteint ses limites, il peut évacuer des pages vers le périphérique de swap sous-jacent. La documentation de Zswap décrit explicitement cet échange : dépenser du temps processeur pour réduire les entrées-sorties du swap.
CRAM change la manière de lire ces données.
Il vise des périphériques mémoire qui compressent et décompressent eux-mêmes les données. Le processeur peut accéder à leur contenu avec des opérations de lecture mémoire ordinaires, sans demander au noyau de restaurer préalablement une page entière depuis un espace de swap compressé. Les pages restent référencées dans les tables qui permettent au système de retrouver les données.
Voilà pourquoi « un ZRAM plus rapide » serait une description insuffisante : CRAM ne se contente pas d’accélérer la même opération.
Et cette différence devient plus claire lorsqu’on suit une lecture.
Lire sans remettre toute la page
Avec Zswap, lorsqu’une application réclame une page placée dans le cache compressé, un défaut de page déclenche sa récupération. Le terme peut inquiéter, mais il ne désigne pas nécessairement une erreur : ici, le système doit simplement remettre les données dans une page utilisable, en les décompressant.
CRAM cherche à éviter ce détour lors des lectures.
Le matériel effectue la décompression au fil des accès. L’application n’a donc pas à attendre que Linux restaure d’abord toute la page dans la mémoire classique. Les accès peuvent se faire à une échelle plus fine, celle des blocs manipulés par le cache du processeur, voire de l’octet.
Il y a toujours une décompression. Elle est prise en charge par le périphérique mémoire, pas par le même parcours logiciel que le swap compressé.
Cette distinction explique l’intérêt des résultats présentés. Elle ne dit pas encore combien de capacité supplémentaire une machine peut réellement exploiter.
La capacité gagnée n’est pas fixe
Prenons un exemple volontairement simplifié.
Supposons qu’un ensemble de données occupant 8 Go sans compression n’en occupe plus que 4 Go une fois compressé. Dans cet exemple, son stockage demande deux fois moins de place. Aucun composant physique n’a grandi : ce sont les données qui occupent moins d’espace.
Ce rapport de deux pour un est une hypothèse pédagogique, pas un résultat attribué à CRAM. Il ne permet pas de conclure qu’une machine équipée de 32 Go se comporterait systématiquement comme une machine de 64 Go.
C’est précisément la difficulté soulevée par le projet : la capacité effective dépend des données. Un périphérique peut annoncer davantage d’espace que sa capacité physique, en comptant sur leur compressibilité. Si celle-ci diminue, Linux doit éviter de se retrouver avec plus de données à stocker que de place réellement disponible. Le descriptif de la présentation place cette question au cœur du travail sur CRAM.
Le débit n’est donc qu’une moitié du sujet.
L’autre, moins spectaculaire, consiste à conserver une capacité sur laquelle le système peut compter.
CRAM Linux : les écritures expliquent la prudence
Dans le mécanisme décrit, les pages placées dans la mémoire compressée sont accessibles en lecture seule. Si une application tente d’en modifier une, cette page est d’abord transférée vers la DRAM classique. Le système ne laisse donc pas les applications écrire librement dans ce niveau compressé comme dans une mémoire ordinaire.
Cette règle donne un sens concret à la formule « gestion spécifique des écritures ».
Le périphérique peut aussi signaler des seuils d’occupation pour indiquer au noyau quand il doit cesser de lui envoyer des données. L’objectif est de maîtriser le remplissage d’une mémoire dont la capacité utile varie avec la compression.
Les performances présentées restent encourageantes. Dans les essais rapportés, les charges en lecture seule atteignent pratiquement celles de la DRAM de référence. Lorsque les écritures entrent en jeu, CRAM reste nettement devant ZRAM, Zswap et le swap classique. La présentation cite notamment TAOBench et FIO.
Mais ces résultats mesurent le comportement de l’ensemble du mécanisme testé. Ils ne signifient pas que les pages compressées deviennent directement modifiables, ni que tous les logiciels obtiendront les mêmes performances.
Je retiens donc « proche de la DRAM dans les essais présentés ». La formule est moins spectaculaire qu’« aussi rapide que la RAM », mais elle conserve l’information nécessaire pour juger le résultat.
Reste la question pratique : sur quelle machine ?
Votre Linux ne peut pas l’activer
CRAM nécessite un périphérique compatible avec cette compression matérielle. L’approche présentée concerne notamment des extensions mémoire CXL, c’est-à-dire des dispositifs permettant d’ajouter un niveau de mémoire accessible au système. Le contexte visé est aujourd’hui celui des infrastructures de datacenter, pas celui d’un simple réglage sur un ordinateur portable.
Au 7 octobre 2026, CRAM n’est pas intégré au noyau Linux principal. Ce n’est ni une commande universelle, ni une solution prête à remplacer votre configuration ZRAM ou Zswap.hwbusters
Pour une recherche « augmenter la RAM sous Linux », la réponse serait donc décevante. Pour une recherche « comprendre CRAM Linux », elle est essentielle : Meta explore une manière différente d’exploiter de la mémoire compressée, avec des résultats prometteurs sur un matériel adapté.
La prochaine preuve à attendre n’est pas seulement un meilleur graphique de débit. C’est la démonstration que Linux peut compter sur cette capacité lorsque les données se compressent moins bien que prévu.
