¿Por qué mmap () es más rápido que sequential IO? [duplicar]

Escuché (lo leí en Internet en alguna parte) que mmap() es más rápido que IO secuencial. ¿Es correcto? Si es así, entonces ¿por qué es más rápido?

Puede ser - hay pros y contras, se enumeran a continuación. Cuando realmente tenga razones para preocuparse, siempre compare ambos.

Aparte de la eficiencia de E / S real, hay implicaciones para la forma en que el código de la aplicación rastrea cuándo necesita hacer la E/S, y hace el procesamiento/generación de datos, que puede a veces afecta el rendimiento de manera bastante dramática.

1) mmap() no se lee secuencialmente. 2) mmap () tiene que buscar desde el propio disco lo mismo que read() 3) El área mapeada no es secuencial, por lo que no hay DMA (?).

¿Entonces mmap() debería ser más lento que read() de un archivo? ¿Cuáles de mis suposiciones anteriores son erróneas?

1) está mal... mmap() asigna una región de espacio de direcciones virtuales correspondiente al contenido del archivo... cada vez que una página en ese espacio de direcciones se accede, se encuentra RAM física para respaldar las direcciones virtuales y el contenido del disco correspondiente falla en esa RAM. Por lo tanto, el orden en el que se realizan las lecturas desde el disco coincide con el orden de acceso. Es un mecanismo de E/S" perezoso". Si, por ejemplo, necesita indexar en una tabla hash enorme que se iba a leer desde el disco, entonces mmaping el archivo y comenzar a hacer acceso significa que la E/S del disco no se realiza secuencialmente y, por lo tanto, puede resultar en un tiempo transcurrido más tiempo hasta que el archivo completo leer en memoria, pero mientras eso sucede, las búsquedas tienen éxito y se puede realizar un trabajo dependiente, y si las partes del archivo nunca son realmente necesarias, no se leen (permita la granularidad de las páginas de disco y memoria, e incluso cuando se usa el mapeo de memoria, muchos sistemas operativos le permiten especificar algunos consejos para mejorar el rendimiento / la eficiencia de la memoria sobre sus patrones de acceso planificados para que puedan leer proactivamente o liberar memoria de manera más agresiva sabiendo que es poco probable que regrese a se).

2) absolutamente cierto

3) "El área mapeada no es secuencial" es vaga. Las regiones mapeadas en memoria son "contiguas" (secuenciales) en el espacio de direcciones virtuales. Hemos discutido que la E / S del disco es secuencial arriba. O, ¿estás pensando en otra cosa? De todos modos, mientras que las páginas se están fallando en, que de hecho pueden ser transferidos utilizando DMA.

Además, hay otras razones por las que el mapeo de memoria puede superar el rendimiento habitual de E / S:

• hay menos copiar:
  • a menudo, las rutinas a nivel de sistema operativo y biblioteca pasan los datos a través de uno o más buffers antes de que lleguen a un buffer especificado por la aplicación, la aplicación luego asigna dinámicamente el almacenamiento, luego copia desde el buffer de E/S a ese almacenamiento para que los datos se puedan usar después de que se complete la lectura del archivo
  • la asignación de memoria permite (pero no fuerza) el uso en el lugar (solo puede grabar un puntero y posiblemente la longitud)
    • continuar accediendo a los datos in situ aumenta el riesgo de intercambio más tarde: el archivo / memory-map podría ser más detallado que las estructuras de datos en las que se podría analizar, por lo que los patrones de acceso a los datos podrían tener más retrasos para fallar en más páginas de memoria
• la asignación de memoria puede simplificar el trabajo de análisis de la aplicación al permitir que la aplicación trate todo el contenido del archivo como accesible, en lugar de preocuparse por cuándo leer otro búfer completo
• la aplicación difiere más a la sabiduría del sistema operativo re número de páginas que están en la RAM física en cualquier punto del tiempo, compartiendo efectivamente una caché de disco de acceso directo con la aplicación
• también-wisher comenta a continuación,"el uso de mapeo de memoria que normalmente utiliza menos llamadas al sistema"
• si varios procesos están accediendo al mismo archivo, deberían poder compartir las páginas de respaldo físicas

También hay razones por las que mmap puede ser más lento-lea el post de Linus Torvald aquí que dice de mmap:

...página de juegos de mesa junto con la culpa (e incluso simplemente TLB miss) la sobrecarga es fácilmente más que el costo de copiar una página en un buen streaming manera...

Y de otro de sus mensajes :

• Costos de instalación y desmontaje bastante notables. Y quiero decir notable . Es cosas como seguir las tablas de página para desmapear todo limpiamente. Es la contabilidad para mantener una lista de todas las asignaciones. Es El flush TLB necesario después de desmapear cosas.

• El fallo de página es caro. Así es como se rellena el mapeo, y es bastante lento.

FWIW, la última vez que esto surgió para mí en el trabajo, la entrada mapeada de memoria fue un 80% más rápida que fread et al para leer registros de bases de datos binarias en una base de datos propietaria, en Linux de 64 bits con archivos de ~170 GB.