Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails
Qu’est ce que la technologie ReadyBoost?
La technologie ReadyBoost est une technologie développée par Microsoft pour Windows Vista. Elle consiste à utiliser une clé USB en tant que sorte de mémoire cache pour stocker des fichiers couramment utilisés dans le but d’y accéder ensuite plus rapidement.
Le principe clé mis en avant: les temps d’accès différents
Le principe clé couramment mis en avant pour justifier le gain de performance est le fait que les clés USB ont des temps d’accès souvent bien meilleurs que les disques durs. En effet, contrairement à un disque dur, une clé USB n’est pas composés de plateaux et de têtes de lecture. Le processus physique de déplacement des têtes est la raison des temps d’accès élevés des disques durs: lorsqu’on accède à de l’information de manière non séquentielle, il faut à chaque fois positionner les têtes de lecture. Les clés USB ne font pas intervenir un tel processus physique, le temps d’accès est du pour l’essentiel à la réactivité de l’électronique de la clé, donc il est plutôt bon.
C’est ce type de discussion sur les temps d’accès que l’on peut souvent entendre pour justifier le ReadyBoost…
Qu’est ce que le SwapBoost pour Linux?
Le procédé appelé par un certain nombre de linuxiens comme le SwapBoost (voire parfois comme le “ReadyBoost pour Linux”) est en fait quelque chose qui n’a rien à voire avec le ReadyBoost (il faut clairement le dire), même si au final, le but de gain de performances dans des conditions similaires est souvent atteint (j’y reviendrais).
Il s’agit en fait tout simplement d’utiliser une clé USB en tant que mémoire swap plutôt que d’utiliser le disque dur. On peut ainsi rendre une configuration plus réactive (cf suite).
Deuxième argument clé pour du ReadyBoost / SwapBoost: des accès concurrents
C’est là un argument que je n’entends ou ne lis pas souvent pour le moins, mais qui me parait néanmoins plus qu’essentiel: lorsqu’on lit sur une clé USB et que on l’utilise (pendant un laps de temps) à 100% de ses performances, le disque dur est “libre pour autre chose”. Le système aura donc tendance (quand c’est justifié) à effectuer 2 opérations de lecture (ou une opération de lecture et une d’écriture, etc.) “en même temps”.
Pour mieux comprendre l’importance de cet argument, il convient de voir plus en détail ce qui se passe souvent lorsqu’une machine “ramme”, cela peut par exemple être le cas à l’ouverture d’un programme lourd, par exemple: très souvent dans ce cas il y a un besoin fort en lecture/écriture sur le système de fichier: cela se traduit par une certaine utilisation du disque dur… Mais en plus de ça, typiquement une configuration qui marche au ralentit est souvent une configuration qui n’a pas assez de mémoire. Cela veut dire que le système va chercher à “créer virtuellement de la mémoire en plus”, dit plus rigoureusement il utilise le swap sur disque pour stocker sur un disque (relativement lent) ce qui “devrait” être stocké en RAM (bien plus rapide). Avoir besoin du swap est donc déjà pas si bon… Mais si en plus il y a beaucoup d’autres accès au même disque en même temps, cela ne va plus très bien: une demande “doublée” sur le disque, de nombreux déplacements des têtes supplémentaires. Bref il devient logique que le système marche au ralentit.
Que ce soit en utilisant ReadyBoost ou SwapBoost, on permet donc (d’une façon différente) de faire des accès concurrents sur deux disques différents, ce qui permet de gagner du temps (on peut aussi en gagner en ayant deux disques durs et en “swappant” sur celui le moins utilisé pour les opérations habituelles sur le système de fichier, ou bien encore en utilisant du RAID, etc…).
C’est donc un réel avantage en plus, complémentaire à celui des temps d’accès réduits sur les clés USB.
Une approche typiquement différente mais des résultats similaires: des raisons?
Comme indiqué plus tôt les deux approches (ReadyBoost et SwapBoost) sont tout à fait différentes. Dans un cas (ReadyBoost) il s’agit de mettre en cache des fichiers sur clé USB, dans l’autre cas (SwapBoost) il s’agit de stocker le swap sur la clé USB.
Dans le cas typique de ralentissement évoqué plus tôt, avec la technologie dite SwapBoost, le principe des accès simultanés marche à la condition que des accès disque au système de fichiers soient nécessaires à ce moment (plus que très probable…). La réduction des temps d’accès due à la technologie Flash de la clé s’appliquera sur les accès au swap (donc à priori il y a des chances pour que ce soit assez utile).
Dans ce même cas avec la technologie ReadyBoost, si la selection des fichiers mis en cache a bien marché (i.e. si le système a bien fait son job), il y a des chances pour qu’il y ait des accès concurrents et aussi un bénéfice du au temps d’accès réduits de la clé.
Bien que les technologies soient fondamentalement différentes, elles tendent donc à déboucher sur le même effet en pratique: un gain de performance.
Quelques détails supplémentaires sur ReadyBoost
Pour que cette technologie soit utilisable, il faut qu’un certain nombre de critères soient remplis concernant la clé, notamment de performances concernant cette clé.
Le système utilise du cryptage pour protéger la confidentialité en cas de vol de la clé.
Il est couramment indiqué que les gains de performances réels ne se produisent que pour des configurations avec “peu de mémoire”, afin de rendre la situation “potable”. Cela serait donc des situations où l’on gagne peut-être beaucoup à éviter Windows Vista…
Quelques détails supplémentaires sur SwapBoost
En fait comme indiqué plus tôt SwapBoost est un nom couramment utilisé et ne décrit pas entièrement comment les choses se passent… (Mais par pitié, évitez d’utiliser le nom ReadyBoost pour Linux!)
Tout dépend donc de comment on s’y prend, et j’espère avoir prochainement l’occasion d’en préciser plus à ce sujet…
Dans la série… (UPDATE)
- Windows’s ReadyBoost vs Linux’s SwapBoost : Quelques détails
- SwapBoost épisode I : Les méthodes simples
- SwapBoost épisode II : Et si on utilisait un simple fichier?
C’est assez sympa comme technologie, dans un cas comme dans l’autre, mais je reste néanmoins sceptique sur sa réelle utilité.
Ca utilise un port USB en plus, nécessite de dédier une clé USB a cet effet, encombre inutilement, pour au final obtenir le même effet qu’un ajout de RAM.
Donc dans le cas ou ca n’est pas possible, c’est clairement une bonne solution de secours, mais a part dans des cas très ciblés, ça reste quand même du bricolage.
Sympa mais pas ultime donc.
Très intéressant, merci beaucoup pour ce très bon billet.
@chriss:
Pour la nécessiter de prendre un port USB rien que pour ça c’est vrai c’est un inconvénient de taille (bien que des hubs existent, cela nécessite un investissement, et il faut choisir au mieux ou les placer si on tient aux performances)
Pour la “nécessite de dédier une clé USB a cet effet”, avec des clés 2GB assez performantes pour du SwapBoost pour 7 euros, ce n’est plus trop un problème…
L’ajout de RAM reste quelque chose à considérer (bien que la RAM est plus couteuse) mais du SwapBoost sur clé reste souvent préférable à du swap sur disque dur. (De toute évidence si tout le monde pouvait se passer du swap facilement ça se saurait.)
Un exemple simple où c’est utile: un module d’1 GB de RAM déjà installé (taille maximum par module pris en charge), pas d’autre connecteur (ou autre connecteur HS d’origine) -> dans ce cas c’est facilement utile (bon certes la plupart du temps avec une telle config on peut aussi souvent ne pas “swapper” du tout).
@macsim: merci!
Interressant comme article.
Je me demandais, ne serait-ce pas encore plus utile de pouvoir utiliser les 2 techno en même temps ? Vu qu’elles ont une approche différente …
@Thib:
Implémenter les deux en même temps? Ça commence à être compliqué mais pourquoi pas… En fait ça risque de se faire naturellement pour ceux qui cumuleraient disque hybride (hd normal cumulé avec de la flash pour l’optimiser) et le “SwapBoost”.
Sinon pour l’implémenter sous Vista, j’avoue que je ne sais pas si Vista laisse utiliser les supports flash pour “swapper”. (Je n’ai pas touché à cet OS sauf 10 minutes sur un portable où il était installé en italien et 10 de plus sur un où il était installé en polonais, bref, j’y ai pas compris grand chose…)
Sous Linux, il faudrait développer tout d’abord le *vrai* équivalent du ReadyBoost (si c’est pas déjà fait), ensuite il serait possible d’essayer.
Après faudrait voir les résultats. Mon avis est qu’il ne serait pas si facile d’avoir une config telle que 3 accès disques aient naturellement lieu en même temps de cette façon. Il y aurait quand même des chances de gagner un peu sur les temps d’accès. Après ça demande vraiment à être testé.
Mais quand on en arrive là on peut aussi songer à faire logiciellement une sorte de RAID entre deux clés pour doubler le débit… Bref les possibilités sont grandes…
Juste une petite précision, si vous avez un portable ou un lecteur interne multi-carte il n’est pas nécessaire d’utiliser un port usb.
Par exemple, dans mon cas, je possède un emplacement dédié à ReadyBoost dans mon portable.
Un truc qui me chagrine par contre et que tu n’as pas évoqué dans ton billet est le nombre limité des cycles de lecture/écriture sur les mémoires flash.
Certes les mémoires flash récentes et de qualité (je précise) ont un cycle d’écriture plus élevé 100.000 cycles voir 1 million pour les mémoire flash dite “industrielles” (mémoire pour l’industrie, pas pour les particuliers lambda) et certaines ont des systèmes de ré-allocation des bits pour ne pas user toujours la même partie de la puce.
Mais typiquement lorsque qu’on l’on utilise linux dans des systèmes embarqués, donc avec système sur de la mémoire flash (en général des cartes Compact Flash, parfois des clefs usb), soit on utilise un système de fichier spécial mémoire flash (JFFS2) ou bien de l’ext2 (non-journalisé) avec l’option noatime, mais surtout jamais de swap sur du support flash. Car les incessantes lectures/écritures peuvent ruiner la mémoire flash assez rapidement et causer problèmes de fiabilité.
@Prometee:
Exact pour la précision. D’ailleurs pour rajouter quelques suppléments à ce sujet, l’efficacité dépend aussi bien sûr des vitesses des supports en question (très variables avec les cartes) et aussi de l’interface utilisée de façon interne (pour certains lecteurs internes c’est comme de l’USB, cependant il existerait d’autres interfaces pour faire passer la carte comme un disque normal ce qui signifie un usage plus faible du CPU).
@tof:
Pour du ReadyBoost ça pourrait durer plus de 10 ans selon certaines sources (http://blogs.msdn.com/tomarcher/archive/2006/06/02/615199.aspx par exemple).
Pour du SwapBoost, c’est très variable, tout dépend de comment on s’y prend (je compte y revenir par un post). Dans le pire des cas, on utilise la méthode la plus naÏve qui soit (une seule partition de swap que l’on active avec un seul “swapon”) et la mémoire flash en question ne gère pas la réallocation. Dans ce cas, seul le fonctionnement de base du swap sous Linux influe.
Il ne faut pas croire que le swap est réellement comme de la mémoire vive (même si avec un adressage virtuel ça peut y ressembler): quand un programme a besoin d’écrire dans une zone qui était dans le swap, le système recopie d’abord le swap en RAM, et les données ne sont réécrites dans le swap qu’après un certain laps de temps. Il n’y a pas écriture directe dans la flash. Cela constitue déjà une première limitation au nombre d’écritures effectuées.
Ensuite, quand le nombre d’écriture dans le swap devient élevé, c’est aussi généralement quand l’usage du swap (en nombre de MOs) devient non négligeable. Autrement dit cela signifie que l’on écrit pas à chaque fois au même endroit. Les limitations de la mémoire flash en nombre d’écritures sont valables pour un nombre d’écriture dans un bloc de taille donnée. Il y a donc un deuxième facteur diminuant l’ampleur du problème.
Pour conclure, je rappellerais également que j’ai indiqué comment on s’y prend (et j’espère revenir sur ce sujet): je n’envisage pas trop de conseiller de prendre les clés les plus “solides” en revanche pour ce qui concerne les commandes Linux employées, on peut adapter un peu… (J’en dis pas trop tout de suite, car en réponse à un commentaire ce serait trop peu…)