Chaque appel système implique des coûts : passage du mode utilisateur au mode noyau, sauvegarde de l'état, vérification des paramètres. Pour un serveur traitant des centaines de milliers d'opérations par seconde, ces coûts s'accumulent pour former une part non négligeable.
Deux rondelles de partage
io_uring crée deux files d'attente circulaires situées dans une zone de mémoire accessible à la fois au programme et au noyau :
- Éléments envoyés — le programme enregistre les requêtes ici
- Données de réception — l'utilisateur consigne ici les résultats renvoyés
Le programme peut mettre en file d'attente des dizaines d'opérations, puis les signaler au noyau en une seule fois. En mode « pollinator », aucun appel système n'est même nécessaire : le noyau détecte lui-même les nouvelles requêtes.
En quoi cela diffère-t-il des méthodes précédentes ?
epoll L'indicateur vous signale quand le fichier est prêt, mais vous devez ensuite l'appeler vous-même read. Il est asynchrone au niveau de l'attente, mais synchrone au niveau de l'exécution. io_uring est asynchrone sur les deux plans : vous envoyez une requête de lecture et recevez le résultat une fois celle-ci terminée.
Cela ne se limite pas non plus aux sockets. Les opérations courantes de lecture et d'écriture de fichiers, l'ouverture de fichiers, le renommage, voire de nombreuses opérations séquentielles interdépendantes, entrent toutes dans cette catégorie.
Le prix
La surface d'attaque est plus vaste, et par le passé, une série de failles a conduit certains fournisseurs à limiter l'utilisation de `io_uring` dans les environnements multi-utilisateurs partagés. Le modèle de programmation est également plus complexe : la gestion du cycle de vie du tampon lors des opérations en cours d'exécution est une source d'erreurs fréquente.
Si votre application n'atteint pas la limite du nombre d'appels système, io_uring n'apporte rien d'autre que de la complexité. Effectuez des mesures au préalable.
Thảo luận