Comment accélérer un SSD avec Linux
Vous avez craqué pour un SSD ? Vous êtes un adepte des manchots ? Il existe un moyen simple d'accélérer (dans certains cas) un SSD sous Linux, en modifiant la façon dont sont gérées les I/O sur le périphérique de stockage.
Linux optimise pour les disques mécaniques
En simplifiant, Linux propose plusieurs schedulers (ordonnanceur) pour la gestion des I/O et celui utilisé par défaut dans la majorité des distributions est optimisé pour les disques mécaniques. Globalement, le CFQ (Completely Fair Queuing) effectue l'équivalent du NCQ au niveau de l'OS, il optimise la gestion des données pour que les têtes de lecture effectuent le chemin le plus court possible. Sauf qu'avec un SSD, c'est totalement inutile : le temps d'accès ne varie pas. Il est possible de modifier le scheduler pour en utiliser un plus simple, qui se contente d'envoyer les données au disque (ici au SSD) et le laisser se débrouiller (mode FIFO). Dans le test effectué par un blogueur, la compilation du noyau est nettement plus rapide avec le scheduler le plus simple qu'avec le CFQ utilisé par défaut : le gain de temps est de 13 % (3 653 secondes contre 4 161).
Attention, pas toujours une bonne idée
Le lecteur impatient s'est arrêté au premier paragraphe, l'adorateur de Microsoft considère que Linux est mauvais, il désoptimise les SSD. Pourtant, il y a encore à dire : le CFQ n'est pas toujours un mauvais choix. Si on compile le noyau en mode multithread, on se rend compte que la tendance s'inverse : le mode FIFO est un peu plus lent que le mode CFQ. La raison vient a priori de la façon de fonctionner des SSD : avec la flash NAND, l'écriture s'effectue par blocs, généralement de 128 ko. Écrire 1 octet ou 126 ko prend dans la pratique environ le même temps. En mode FIFO, chaque thread va envoyer ses données, écrites directement sur le SSD. En mode CFQ, il va recevoir les données et les ordonner et il va donc envoyer plus de données d'un coup. Si dans le premier cas on envoie cinq fois de suite 10 ko et dans le second une seule fois 50 ko, le gain peut être intéressant.
Dans les faits, le mode CFQ est plus efficace dans certains cas, le FIFO dans d'autres. Mais il est intéressant d'avoir le choix et surtout de pouvoir choisir le mode le plus adapté.
- Stockage,
- Stockage pro,
- ssd ,
- linux ,
- accélérer
- iLife 09 : Apple va vous faire apprécier OpenCL
- Eurocom : un Core i7 dans un notebook !
- Intel va-t-il payer la taxe SLI ?
- Test du radiateur GPU Scythe Musashi (Cowcotland)
- NVIDIA : d'autres GPU mobiles défectueux ?
- Bon anniversaire... Pentium 4 Prescott
- SSD : de l'importance du contrôleur (MatBe)
- Les meilleures configurations de février 2009
- Netgear intègre Kaspersky dans ses appareils
- Intel annulerait ses CPU-GPU, en attendant le 32 nm
- Larrabee va faire combattre les monstres et les aliens
- Des SSD de 192 Go chez Transcend
- Free présente la nouvelle AliceBox
- Un nouveau Core i7 chez Intel : plus rapide
- Seagate annonce un disque dur de 2 To pour dans 6 mois
- Chute des ventes : CPU -9 %, GPU -30 %
- Free : 3 millions de freenautes dégroupés
- Malgré la crise, les européens achètent plus de PC






Dans ce cas il suffirait de programmer un mode FIFO qui attend d'avoir des données de la taille des blocs du SSD non??? (je suppose que si c'était si simple ce serait déjà fait ou que tout simplement ce sera fait)
Le plus simple c'est d'utiliser un bench qui n'est pas CPU depandant.
Le CFQ aura tjrs des perfs en I/O supérieur au FIFO, SSD ou non. Cepandant dans une compilation de noyau, le temps CPU occuper pour optimiser le traitement des données fait défaut et donc rallonge la compilation.
Il met plus d'une heure à compiler son noyau ? aussi rapide que mon athlon xp !
Sur son blog il à publié un autre bench ou déjà il se met à utiliser ses cores, et ou CFQ sort gagnant.
et il n'a même pas essayé les autres schedulers io ni même d'autres systèmes de fichiers...
Le plus simple serait en effet de faire un scheduler spécial qui regroupe les écritures "proches" mais ne change pas l'ordre des lectures.
Le plus simple c'est d'utiliser un bench qui n'est pas CPU depandant.Le CFQ aura tjrs des perfs en I/O supérieur au FIFO, SSD ou non. Cepandant dans une compilation de noyau, le temps CPU occuper pour optimiser le traitement des données fait défaut et donc rallonge la compilation.
Ce qui veut dire qu'en pratique, si je veux recompiler mon kernel et que j'ai un SSD, faut que je désactive le CFQ.
CQFD.
Ce qui veut dire qu'en pratique, si je veux recompiler mon kernel et que j'ai un SSD, faut que je désactive le CFQ.
CQFD.
Faut surtout compiler avec tes deux cores :
http://www.alphatek.info/2009/02/0 [...] sd-part-2/
Faut surtout compiler avec tes deux cores :
http://www.alphatek.info/2009/02/0 [...] sd-part-2/
ce qui sera d'une parfaite utilité pour ceux qui ont (hélas encore) des CPU mono-cores
quid de la durée de vie si on écrit sur le SSD a chaque modification d'un octet.
ce qui sera d'une parfaite utilité pour ceux qui ont (hélas encore) des CPU mono-cores
J'ai un monocore, mais un -j 2, ça fait quand même du bien. Ça permet au hasard de faire quelque chose pendant qu'un processus est bêtement bloqué dans de l'I/O.
Faudrai qu'il fasse le test avec un -j maintenant.
C'est pas neuf cela, il y a un an quand les permiers disques SSD dans les netbook sont sortis cela a deja été mis en avant par la communauté.