Baisse des performances des pipes Linux

vmsplice est trop rapide

• Certains programmes utilisent l’appel système vmsplice pour déplacer les données plus rapidement à travers des pipes
• Il a été constaté que les pipes Linux sont plus lents que prévu lorsqu’on n’utilise pas vmsplice
• Un programme est en cours de développement pour encoder/décoder rapidement du code Morse, et il utilise des pipes pour cela

Écrire des données dans des conditions idéales

• Le programme ci-dessous copie les données sans appel système
• Il s’exécute à une vitesse de 167 Go/s avec AVX-512
• En désactivant AVX-512 et en testant avec AVX2 et SSE2, on obtient la même vitesse (167 Go/s)
• Tant que la vectorisation est utilisée, il est possible d’atteindre 167 Go/s

Écrire réellement des données dans un pipe

• Après avoir écrit un programme qui envoie des données dans un pipe et l’avoir mesuré, une vitesse de 17 Go/s a été observée
• C’est 10 fois plus lent que l’écriture dans un buffer
• Le profilage montre que la majeure partie du temps est consommée par les appels write
• La fonction pipe_write passe beaucoup de temps à allouer des pages mémoire
• La copie des données elle-même ne représente que 20 % du temps CPU, mais reste malgré tout deux fois plus lente que __memset_avx512_unaligned_erms

L’aide de vmsplice

• vmsplice déplace les buffers de l’espace utilisateur vers le kernel sans les copier
• Avec vmsplice, il est possible d’atteindre 210 Go/s
• vmsplice contourne la partie coûteuse de l’appel système write

Conclusion

• Écrire dans un pipe est 10 fois plus lent qu’écrire dans la mémoire brute
• Cela est dû au coût du verrouillage des buffers et à celui de la sauvegarde et de la restauration du contexte SIMD
• splice et vmsplice évitent ces coûts et déplacent les données efficacement

Résumé GN⁺

• Cet article explique comment maximiser les performances des pipes Linux avec vmsplice
• vmsplice améliore fortement les performances en déplaçant directement les données sans les copier dans l’espace kernel
• C’est utile pour les programmes de traitement de données à haute vitesse comme l’encodage/décodage du code Morse
• D’autres projets offrant des fonctionnalités similaires incluent splice et sendfile

[GN⁺]

Commentaires Hacker News

• La raison pour laquelle JMP n’est pas remplacé par RET est l’option CONFIG_RETHUNK

  • Dans le désassemblage d’objdump, on peut voir que RET est remplacé par JMP __x86_return_thunk
  • Liens associés : lien1, lien2

• Les instructions NOP au début et à la fin de la fonction permettent à ftrace d’insérer des instructions de traçage

  • Elles proviennent des macros ASM_CLAC et ASM_STAC
  • Si X86_FEATURE_SMAP est détecté, elles sont remplacées à l’exécution par les instructions CLAC et STAC
  • Liens associés : lien3, lien4, lien5

• Le side project d’un utilisateur propose un appel système fournissant un ring buffer pour les descripteurs de fichiers

  • Si les deux extrémités du pipe prennent en charge le ring buffer, il devient possible de mapper le même ring buffer pour permettre des E/S zero copy sans appel au noyau
  • Il cherche des collaborateurs
  • Lien associé : lien6

• Dire que les pipes Linux sont « lents », c’est comme dire qu’une Toyota Corolla est « lente »

  • C’est largement assez rapide dans la plupart des cas
  • Sauf cas extrêmes, il n’y a pas besoin de chercher plus rapide

• Sur les CPU modernes, rep movsb est aussi rapide que les versions vectorisées les plus rapides

  • Le nom de la fonction du noyau copy_user_enhanced_fast_string le laisse entendre
  • Les fonctionnalités CPU ERMS et FSRM rendent cela possible

• AVX512 consomme beaucoup d’énergie et déclenche un ajustement de la fréquence du CPU

  • Liens associés : lien7, lien8

• Le « hug of death » de Hacker News est en train de se reproduire

  • Grâce aux pages WordPress mises en cache, la situation est meilleure, mais cela prend encore quelques secondes

• Il serait intéressant de voir une version utilisant io_uring

  • On pourrait éviter les copies et réduire le surcoût des appels système grâce au noyau et aux buffers prépartagés

• Affirmer qu’un blog met environ 20 secondes à se charger est audacieux

• Presque toutes les formes d’IPC sont « lentes »

  • C’est le prix en performance qu’on a décidé de payer pour la sécurité

• Au départ, il ne comprenait pas pourquoi splice était si lent

  • Il a souligné pourquoi c’était plus lent que vmsplice, mais sans que la raison soit claire
  • Il doit y avoir une raison pour laquelle on ne peut pas le réimplémenter avec vmsplice