Quand on parle de records en informatique, il est souvent question de GHz, d'overclocking nécessitant un système de refroidissement (et une consommation) un peu dingue. Mais on peut prendre ce sujet autrement, en cherchant comment obtenir le meilleur résultat en améliorant le code. C'est ce que fait Jens Axboe.
Jens Axboe est un développeur connu des passionnés de stockage et de performances. Développeur chez Facebook spécialisé dans l'optimisation des E/S pour le noyau Linux, il est à l'origine de l'application fio, largement utilisée pour mesurer les débits, latence et autres IOPS des HDD et SSD du marché sous Linux.
Il est aussi à l'origine d'un moteur d'E/S de plus en plus utilisé, notamment parce qu'il se veut simple et très efficace : io_uring. Il est intégré au noyau Linux depuis les versions 5.1x, exploitable via la bibliothèque liburing.
La course à la performance ce n'est pas que Cinebench et l'azote
Pour montrer ses capacités, Axboe s'est donné pour défi fin septembre d'obtenir le meilleur score possible avec deux SSD (Optane Gen 2, NVMe) sur un cœur CPU (Ryzen 9 5950X). Il s'agit de lecture aléatoire sur des blocs de 512 octets, un exercice dans lequel la 3D XPoint telle qu'utilisée par Intel offre plutôt de bons résultats.
Avec sa configuration précédente (Ryzen 7 3970X, un SSD) il obtenait 3,8 MIOPS. La nouvelle obtenait au départ 5,1 MIOPS, avec 2 500 Mo/s de bande passante. Depuis, il ne cesse de dépasser ses précédents records, optimisant (entre autres) le code d'io_uring, intégré au fur et à mesure au noyau Linux.
Avec la branche 5.16 début octobre il passait à 5,7 MIOPS précisant que cela revient à 175 ns par IO, des résultats plus élevés dans différentes situations face au classique libaio. Quelques jours plus tard, il passait la barre des 6 MIOPS et vient de dépasser les 7 MIOPS avec une latence réduite à 3,4 µs. Il dit désormais travailler à de nouvelles optimisations.
Cap sur les 8 MIOPS, et après ?
Ainsi, il espère dépasser les 8 MIOPS d'ici peu, un record qui fera envie à de nombreux développeurs qui cherchent à tirer au mieux parti de leurs baies de stockage. Un élément de plus en plus critique dans les performances globales d'un système, notamment lorsque de très gros jeux de données sont à traiter en temps réel.
Cela montre néanmoins que le travail d'optimisation logicielle et sur les outils intégrés au noyau d'un OS peuvent avoir un impact non négligeable, demandant la plus grande attention.
Notez d'ailleurs qu'un script de test est directement accessible dans le code de fio. Il est notamment développé par un français, lui aussi spécialisé dans le développement bas niveau et l'optimisation des performances, travaillant chez Criteo, connu des anciens de Mandrake/Mageia, passé par Red Hat et cofondateur de Kernel Recipes : Erwan Velu.
Commentaires (22)
#1
Merci Monsieur
#2
pour comparaison, les optane 2 ils tournent à combien de MIOPS sous windows ?
pour voir si c’est “juste pour rattraper” le voisin d’en face, ou pour le ridiculiser avec du beau code :)
#3
Je doute que qui que ce soit utilise Windows pour les usages visés
En tous cas les tests de ce genre de composants se fait le plus souvent sous Linux via fio, surtout pour du 512B RR donc je ne penses pas qu’on puisse répondre simplement à la question. Je testerai si je récupère un Optane 
Mais sur le fond, l’idée est plus d’obtenir de gros scores avec une lib native du kernel sans avoir à passer par des couches spécialisées comme SPDK par exemple (qui est plus complexe à mettre en œuvre).
#4
La vitesse des E/S est un domaine où Linux est déjà plus performant, je pense qu’avec ce type de driver il enfonce le clou.
#5
Envoi un email ou tweet à Intel France demande leur si yen a pas un qui traine dans un coin et qu’il pourrait te prêter le temps de.
#6
J’ai déjà des choses en cours là dessus
#7
En fait ce qui est notable, c’est surtout que là c’est sur un seul coeur. L’optimisation monothread est folle pour gratter à ce point.
#8
Aujourd’hui Windows n’a pas d’équivalent à io_uring, mais ça arrive : https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/
#9
merci les gens
#10
Ici on parle de perf mono-coeur ce qui n’induit pas mono-thread.
Nous sommes ici sur 1 coeur physique, 2 coeurs logiques cart le SMT est activé.
Ensuite, le bench est executé avec plusieurs threads pour tirer partie le plus possible du paralellisme.
Donc c’est du mono-coeur mais multi-threadé sur plusieurs disques.
L’idée étant de voir jusqu’où on peut emmener un seul coeur physique en terme d’IOs.
#11
Ça sera vraiment intéressant pour les devs quand ça sera intégré dans les librairies d’I/O plus haut niveau et multiplateformes couramment utilisées.
Personnellement j’attend
https://github.com/chriskohlhoff/asio/issues/401
et
https://github.com/libuv/libuv/issues/1947
#12
Ca me fait toujours mal de voir de tels talents travailler pour des boites d’enfoirés comme FB et Criteo…
#13
C’est pas parce qu’il a du talent que c’est une “bonne personne”. ReiserFS inside. Linus Torvald n’a pas l’air d’être très sympa à cotoyer non plus d’ailleurs, ni Richard Stallman.
#14
je ne juge pas les gens, je juge leur boite
#15
Et à l’inverse on peut bosser pour des boites mal perçues tout en étant quelqu’un de bien (on en connait pas mal). D’ailleurs, ceux qui utilisent du logiciel libre doive en général beaucoup à de tels profils (parce que si t’enlève les grosses boites des contributions kernel par exemple et que tu gardes que les participations de ceux qui ont un avis à donner, ça fait un sacré trou).
PS : quant à définir le bien et le mal, on va s’éviter les cours de philo de comptoir ;)
#16
Hum c’est mignon et pas du tout réducteur dis donc.
Bah disons que ça nous permet de faire avancer le libre, les constructeurs, le hard, le soft pour le bien de tout le monde. Et que tu le veuilles ou pas, tu en profites tous les jours.
Libre à chacun de trouver sa route pour contribuer à cet eco-système.
#17
Effectivement: Microsoft, Oracle, IBM/Lenovo (avec une grosse partie optimisation pour le stockage)
Facebook a aussi forcé PHP à s’améliorer pour faire face à l’espèce de fork ultra performant qu’ils avaient.
En tout cas, on sent la convergence entre les technos SSD vers ethernet, les formats de SSD, les solutions très haute perfs et l’optimisation des perfs de solutions existantes, il doit y avoir un goulet d’étranglement sur l’extraction des infos du stockage…
#18
Ça ce n’est vrai que si les opérations sont toujours séquentielles, ce qui me semble-t-il n’est pas le cas sur les SSD.
#19
Détrompez-moi, mais les IO ne nécessitent que peu de puissance de calcul. Hors le propre de la parallélisation des processus, c’est que plus on parallélise, plus on a besoin de ressources pour gérer la parallélisation. Ce n’est donc efficace que sur les processus lourds qui nécessitent un traitement intensif des données, non sur la gestion des IO.
#20
Je pense que ce n’est pas tant un problème de puissance de calcul que d’ordonnancement. Il est important d’optimiser les IO pour maximiser la bande passante du périphérique sans pour autant provoquer les IO_WAIT qui vont bloquer le CPU core sur lequel tourne le process qui a fait la demande.
#21
Mea culpa, je voulais bien dire monocoeur.
C’est exactement ça : un flux qui attend ne fait rien…
Le petit ordonnanceur interne a la libraire doit être aux petits oignons…
#22
Nan mais c’est cool, hein… mais vu ce que font ces boites sur la vie privée et la démocratie, le boulot en question est très loin de compenser.
Après, t’as l’air d’être à l’aise avec ta conscience, tant mieux pour toi. Loin de moi l’idée de te dire ce que tu as à faire.