Bonjour.
J'ouvre ce sujet pour discuter du choix de l'IO scheduler pour un disque SSD.
Ayant acheté un SSD et après avoir récolté des infos sur le sujet je n'ai pas réussi à trouver une réponse suffisamment marquée.
Suivant les tutos / articles / tips, j'ai vu les possibilités suivantes :
echo noop /sys/block/sdb/queue/scheduler
ou
echo deadline > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/fifo_batch
ou
conserver le cfq !
Pour les liens les plus intéressants car donnant plus qu'une commande, nous avons :
-
http://dropzone.tamu.edu/techpubs/2009/TAMU-ECE-2009-02.pdf
Avec un schéma en page 3 qui semble donner raison à noop. Il me semble aussi qu'il est question d'amélioration de cfq (je ne sais pas si c'est juste à titre de recherche ou si c'est allé plus loin : pour l'instant j'ai lu rapidement et pas encore en entier ...).
-
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=41647e7a91338dba21773a16af7474ef95e0929e
CFQ currently applies the same logic of detecting seeky queues and grouping them together for rotational disks as well as SSDs.
For SSDs, the time to complete a request doesn't depend on the request location, but only on the size.
This patch therefore changes the criterion to group queues by request size in case of SSDs, in order to achieve better fairness.
Ce lien est donné par MJules ici
http://forum.hardware.fr/hfr/OSAlternatifs/Hardware-2/recensement-optimisation-conseils-sujet_69473_16.htm#t1227465.
-
https://rawhidewatch.wordpress.com/2009/04/13/ext4-on-intel-x25-m-ssd-needs-nodelalloc/
... UPDATE:
Jeff Moyer pointed out that recent versions of the CFQ elevator has smart SSD detection. If SSD is detected, it disables idling during random access reads because the penalty for reading is not severe. He thinks you are better off using the default CFQ scheduler with these drives. Jeff also pointed out that elevator=noop will also do write combining.
-
http://performance.izzop.com/content/ssd-mesures
Les résultats sont différent suivant le noyau ...
Le cache tend à lisser les différences entre les scheduler (hdparm sans option --direct).
Noop gagne a tout les coups en accès direct (hdparm avec option --direct). En même temps, la différence n'est pas très grande.
Il y a aussi d'autres test avec gzip, de la compilation ...
Pour ce qui me concerne, j'ai fais quelques petits tests hdparm, avec et sans --direct.
En gros :
- "hdparm -t" me donne 250 Mb/s quelque soit le scheduler.
- "hdparm -t --direct" me donne 261 quelque soit le scheduler.
Bref, en résultat, je n'ai pas trouvé le gagnant pour le I/O scheduler idéal pour les SSD ...