Différence entre POSIX AIO et libaio sur Linux?
Ce que je semblent comprendre:
POSIX AIO APIs sont prototypés dans <aio.h> et vous liez votre programme avec libert(-lrt), tandis que le libaio APIs dans <libaio.h> et votre programme est lié avec libaio (-laio).
Ce que je ne peux pas comprendre:
1.Le noyau de la poignée de l'une de ces méthodes différemment?
2.Est le drapeau O_DIRECT obligatoire pour l'utilisation de l'un ou l'autre?
comme mentionné dans ce post , libaio fonctionne très bien sans O_DIRECT en utilisant libaio .OK, compris mais:
selon R. Love's Linux System Programming Livre, Linux prend en charge aio (qui je suppose est POSIX AIO) sur les fichiers réguliers seulement si ouvert avec O_DIRECT .Mais un petit programme que je écrit (en utilisant aio.h, lié à-lrt) qui appelle aio_write sur un fichier ouvert sans le drapeau O_DIRECT fonctionne sans problème.
1 réponses
sur linux, les deux implémentations de L'AIO sont fondamentalement différentes.
le POSIX AIO est une implémentation au niveau de l'utilisateur qui effectue le blocage normal des entrées/sorties dans plusieurs threads, donnant ainsi l'illusion que les entrées/sorties sont asynchrones. La principale raison de faire ceci est que:
- il fonctionne avec n'importe quel système de fichiers
- cela fonctionne (essentiellement) sur n'importe quel système d'exploitation (gardez à l'esprit que la libc de gnu est portable)
- il fonctionne sur les fichiers dont la mise en tampon est activée (c.-à-d. pas de drapeau O_DIRECT)
le principal inconvénient est que la profondeur de votre file d'attente (c'est-à-dire le nombre d'opérations en cours que vous pouvez avoir dans la pratique) est limitée par le nombre de threads que vous choisissez d'avoir, ce qui signifie également qu'une opération lente sur un disque peut bloquer une opération allant à un disque différent. Il affecte également quels I / Os (ou combien) est vu par le noyau et le planificateur de disque aussi bien.
le noyau AIO (io_submit() et.al.) est le support du noyau pour les opérations d'E/S asynchrones, où les requêtes io sont effectivement mises en file d'attente dans le noyau, triées par n'importe quel planificateur de disque que vous avez, probablement certaines d'entre elles sont transmises (dans un ordre quelque peu optimal que l'on espère) au disque réel sous forme d'opérations asynchrones (en utilisant TCQ ou NCQ). La principale restriction de cette approche est que tous les systèmes de fichiers ne fonctionnent pas aussi bien ou pas du tout avec async I/O (et peuvent retomber en bloquant sémantique), les fichiers doivent être ouverts avec O_DIRECT qui est livré avec un grand nombre d'autres restrictions sur les requêtes D'e/s. Si vous ne parvenez pas à ouvrir vos fichiers avec O_DIRECT, cela peut encore "fonctionner", car vous récupérez les bonnes données, mais ce n'est probablement pas fait de manière asynchrone, mais cela revient à bloquer la sémantique.
Aussi garder à l'esprit que io_submit() peut effectivement bloquer sur le disque dans certaines circonstances.