script - copia de seguridad de E/S de archivo asíncrono en Linux
script para copiar archivos de un servidor a otro linux (3)
A menos que desee escribir su propio grupo de subprocesos IO, la implementación de glibc es una solución aceptable. En realidad, funciona sorprendentemente bien para algo que se ejecuta completamente en el mundo del usuario.
La implementación del kernel no funciona con IO con búfer en absoluto en mi experiencia (¡aunque he visto a otras personas decir lo contrario!). Lo cual está bien si quiere leer grandes cantidades de datos a través de DMA, pero por supuesto que es una gran pérdida de tiempo si planea aprovechar la memoria caché del búfer.
También tenga en cuenta que las llamadas AIO del kernel en realidad pueden bloquear. Hay un buffer de comando de tamaño limitado, y las lecturas grandes se dividen en varias más pequeñas. Una vez que la cola está llena, los comandos asíncronos se ejecutan sincrónicamente. Sorpresa. Me he encontrado con este problema hace uno o dos años y no he podido encontrar una explicación. Preguntar me dio la respuesta "Sí, por supuesto, así es como funciona".
Por lo que he entendido, el interés "oficial" en admitir aio almacenado en memoria intermedia tampoco es terriblemente bueno, a pesar de que varias soluciones de trabajo parecen estar disponibles durante años. Algunos de los argumentos que he leído estaban en la línea de "no quieres usar los búferes de todos modos" y "nadie necesita eso" y "la mayoría de las personas ni siquiera usan epoll todavía". Entonces, bueno ... meh.
Ser capaz de obtener una epoll señalada por una operación de epoll completa fue otro problema hasta hace poco, pero mientras tanto, esto funciona realmente bien a través de eventfd .
Tenga en cuenta que la implementación de glibc generará hilos a pedido dentro de __aio_enqueue_request . Probablemente no sea gran cosa, ya que los hilos de desove ya no son terriblemente caros, pero uno debe ser consciente de ello. Si su comprensión de iniciar una operación asincrónica es "devuelve inmediatamente", entonces esa suposición puede no ser cierta, ya que puede estar generando algunos subprocesos primero.
EDITAR :
Como nota al margen, en Windows existe una situación muy similar a la de la implementación AIO de glibc donde la suposición de "devoluciones inmediatamente" de poner en cola una operación asincrónica no es verdadera.
Si todos los datos que deseaba leer están en la memoria caché del búfer, Windows decidirá que ejecutará la solicitud de forma síncrona , porque de todos modos finalizará inmediatamente. Esto está bien documentado, y ciertamente también suena genial. Excepto en el caso de que haya unos pocos megabytes para copiar o en caso de que otro hilo tenga fallas de página o IO concurrentemente (compitiendo por el bloqueo) "inmediatamente" puede ser un tiempo sorprendentemente largo. He visto tiempos "inmediatos" de 2 -5 milisegundos. Lo cual no es problema en la mayoría de las situaciones, pero, por ejemplo, bajo la restricción de un tiempo de cuadro de 16,66 ms, probablemente no desee arriesgarse a bloquear durante 5 ms al azar. Por lo tanto, la suposición ingenua de "puede hacer Async IO desde mi hilo de renderizado no es un problema, porque async no bloquea" es defectuosa.
Estoy buscando la manera más eficiente de hacer E / S de archivos asíncronos en Linux.
La implementación POSIX glibc usa hilos en el territorio del usuario.
La API nativa de aio kernel solo funciona con operaciones sin búfer, existen parches para que el kernel agregue soporte para operaciones de búfer, pero esos tienen> 3 años de antigüedad y parece que a nadie le importa integrarlos en la línea principal.
Encontré muchas otras ideas, conceptos, parches que permitirían E / S asíncronas, aunque la mayoría en artículos que también tienen más de 3 años. ¿Qué hay de todo esto realmente disponible en kernel de hoy? He leído sobre los servlets, los arsenales, las cosas con hilos del kernel y más cosas que ni siquiera recuerdo en este momento.
¿Cuál es la forma más eficiente de hacer entradas / salidas de archivos asíncronos almacenados en el núcleo de hoy?
El material parece viejo - bueno, es viejo - porque ha existido por mucho tiempo y, aunque de ninguna manera es trivial, es bien entendido. Una solución que puede levantar se publica en el excelente e inigualable libro de W. Richard Stevens (lea "Biblia"). El libro es el tesoro raro que es claro, conciso y completo: cada página da un valor real e inmediato:
Programación avanzada en el entorno UNIX
Otros dos, también de Stevens, son los dos primeros volúmenes de su colección de Programación en Red Unix :
Volumen 1: The Sockets Networking API (con Fenner y Rudoff) y
Volumen 2: Comunicaciones entre procesos
No puedo imaginar estar sin estos tres libros fundamentales; Estoy estupefacto cuando encuentro a alguien que no ha oído hablar de ellos.
Todavía más de los libros de Steven, tan precioso:
No creo que la implementación del kernel de Linux de E / S de archivo asíncrono sea realmente utilizable a menos que también use O_DIRECT, lo siento.
Hay más información sobre el estado actual del mundo aquí: https://github.com/littledan/linux-aio . Fue actualizado en 2012 por alguien que solía trabajar en Google.