E / S de fichiers asynchrones tamponnées sur Linux

Question

Je suis à la recherche de la façon la plus efficace de le faire asynchrone e/S de fichier sur linux.

POSIX glibc mise en œuvre utilise des threads en userland.

Le natif de l'aio noyau de l'api ne fonctionne qu'avec les barrettes de mémoire des opérations, les correctifs pour le noyau pour ajouter le support du tampon opérations existent, mais celles-ci sont >3 ans et personne ne semble se soucier de les intégrer dans la canalisation principale.

J'ai trouvé plein d'autres idées, des concepts, des patchs qui permettrait d'e/S asynchrones, bien que la plupart d'entre eux dans les articles qui sont aussi >3 ans. Ce que tout cela est vraiment disponible dans l'actuel noyau? J'ai lu sur les servlets, acalls, des trucs avec des threads du noyau et de plus en plus de choses, je ne me souviens même plus de la droite maintenant.

Quel est le moyen le plus efficace pour faire tampon asynchrone de fichiers d'entrée/sortie dans l'actuel noyau?

Answer 1

Sauf si vous voulez écrire votre propre IO pool de threads, la mise en œuvre de la glibc est une solution acceptable. Il fonctionne étonnamment bien pour quelque chose qui fonctionne entièrement en userland.

Le noyau de la mise en œuvre ne fonctionne pas avec tampon IO dans mon expérience (même si j'ai vu d'autres personnes disent le contraire!). Ce qui est bien si vous voulez lire d'énormes quantités de données via DMA, mais bien sûr, il suce le gros temps si vous prévoyez de prendre avantage de la mémoire tampon.
Notez également que le noyau AIO appels peuvent effectivement bloquer. Il y a une limitation de la taille mémoire tampon de commande, et les grandes lectures sont divisés en plusieurs petits. Une fois la file d'attente est pleine, commandes asynchrones exécuter de manière synchrone. Surprise. J'ai rencontré ce problème a un an ou deux et ne pouvait pas trouver une explication. Demander autour m'a donné le "oui bien sûr, c'est comment ça fonctionne" réponse.
De ce que j'ai compris, le "officielle" de l'intérêt à appuyer le tampon aio n'est pas très grand non plus, en dépit de plusieurs solutions de travail semblent être disponibles pendant des années. Certains des arguments que j'ai lu ont été sur les lignes de "vous ne voulez pas utiliser de tampons de toute façon" et "personne n'a besoin que" et "la plupart des gens ne sont même pas utiliser epoll encore". Alors, eh bien... meh.

Être en mesure d'obtenir un epoll marqué d'une opération asynchrone est une autre question, jusqu'à récemment, mais en attendant, cela fonctionne vraiment bien via eventfd.

Notez que la glibc mise en œuvre sera fait spawn des fils sur demande à l'intérieur d' __aio_enqueue_request. Il n'est probablement pas une grosse affaire, depuis la ponte des threads n'est pas que terriblement cher, mais il faut être conscient de cela. Si votre compréhension de démarrage d'une opération asynchrone est "retourne immédiatement", alors que l'hypothèse ne peut pas être vrai, car il peut être frai certains fils en premier.

EDIT:
Au passage, sous Windows, il existe une situation très semblable à celle de la glibc AIO mise en œuvre où le "retourne immédiatement" hypothèse de la mise en attente d'une opération asynchrone n'est pas vrai.
Si toutes les données que vous voulez lire est dans le cache de tampons, Windows va décider à la place d'exécuter la demande de façon synchrone, parce que ça va se terminer immédiatement de toute façon. C'est bien documenté, et, certes, les sons grande, trop. Sauf en cas il y a quelques méga-octets à copier ou dans le cas où un autre thread a des défauts de page ou t IO simultanément (donc en compétition pour le verrouillage de l') "immédiatement" peut être étonnamment longtemps-je l'ai vu "immédiate" de temps de 2 à 5 millisecondes. Ce qui n'est pas un problème dans la plupart des cas, mais par exemple sous la contrainte d'un 16.66 ms cadre de temps, vous avez sans doute ne voulez pas de risque de blocage de 5ms à des moments aléatoires. Ainsi, l'hypothèse naïve de "peut faire async IO de mon thread de rendu, pas de problème, parce que async ne pas bloquer" est erronée.

Answer 2

Le matériel semble de vieux-eh bien, c' est vieux, car il a été autour depuis longtemps et, bien que non négligeable, est bien comprise. Une solution, vous pouvez ascenseur est publié dans W. Richard Stevens superbe et unique livre (lire "la bible"). Le livre est un trésor rare qui est clair, concis et complet: chaque page donne réels et immédiats de la valeur:

    Advanced Programming in the UNIX Environment

Deux autres, également par Stevens, sont les deux premiers volumes de son Réseau Unix Programmation de la collection:

   Volume 1: Les Sockets Réseau API (avec Fenner et Rudoff) et
   Volume 2: Les Communications Interprocessus

Je ne peux pas imaginer être sans ces trois fondamentaux des livres, je suis bouche bée quand je trouve quelqu'un qui n'a pas entendu parler d'eux.

Encore plus de Steven livres, tout aussi précieux:

   TCP/IP Illustrated, Vol. 1: Les Protocoles

Answer 3

Je ne pense pas que l'implémentation du noyau Linux d'E / S de fichiers asynchrones soit vraiment utilisable à moins que vous n'utilisiez également O_DIRECT, désolé.

Vous trouverez plus d'informations sur l'état actuel du monde ici: http://code.google.com/p/kernel/wiki/AIOUserGuide . Il a été mis à jour en 2012 par un googleur.