H2o: por qué necesitamos MAP_SHARED para h2o_buffer_reserve ()

Creado en 30 dic. 2017  ·  3Comentarios  ·  Fuente: h2o/h2o

https://github.com/h2o/h2o/blob/master/lib/common/memory.c#L272

¿Hay algún otro proceso que acceda a él? si no, ¿por qué no establecer MAP_PRIVATE

Además, ¿podemos usar mremap (2) en lugar de mmap (2) y munmap (2) en una plataforma que admita mremap?

Comentario más útil

¿Hay algún otro proceso que acceda a él? si no, ¿por qué no establecer MAP_PRIVATE?

La intención de usar mktemps + fallocate + mmap es crear un búfer con respaldo de archivo para que la cantidad máxima de espacio que se puede usar para almacenar datos en búfer esté restringida por el _espacio libre del disco en lugar del intercambio_. MAP_PRIVATE entra en conflicto con ese objetivo.

Además, ¿podemos usar mremap (2) en lugar de mmap (2) y munmap (2) en una plataforma que admita mremap?

Eso sería posible asumiendo que las páginas agregadas no serán anónimas. Tenga en cuenta también que si el uso de mremap muestra un cambio notable en el rendimiento, eso significaría que deberíamos ver cómo minimizar la posibilidad de que las páginas se muevan desde que se anuló la asignación (ya sea de forma permanente o como parte de la reasignación) de las páginas asignadas. es la operación más cara. Y eso no significa necesariamente que debamos usar mremap .

De todos modos, almacenar en búfer una gran cantidad de datos es una estrategia secundaria y no creo que sea una buena idea dedicar esfuerzos a mejorar el rendimiento. Preferiría trabajar en la adopción de la solicitud de transmisión (consulte el n. ° 1357) a otros controladores que no sean el controlador de proxy.

Todos 3 comentarios

¿Hay algún otro proceso que acceda a él? si no, ¿por qué no establecer MAP_PRIVATE?

La intención de usar mktemps + fallocate + mmap es crear un búfer con respaldo de archivo para que la cantidad máxima de espacio que se puede usar para almacenar datos en búfer esté restringida por el _espacio libre del disco en lugar del intercambio_. MAP_PRIVATE entra en conflicto con ese objetivo.

Además, ¿podemos usar mremap (2) en lugar de mmap (2) y munmap (2) en una plataforma que admita mremap?

Eso sería posible asumiendo que las páginas agregadas no serán anónimas. Tenga en cuenta también que si el uso de mremap muestra un cambio notable en el rendimiento, eso significaría que deberíamos ver cómo minimizar la posibilidad de que las páginas se muevan desde que se anuló la asignación (ya sea de forma permanente o como parte de la reasignación) de las páginas asignadas. es la operación más cara. Y eso no significa necesariamente que debamos usar mremap .

De todos modos, almacenar en búfer una gran cantidad de datos es una estrategia secundaria y no creo que sea una buena idea dedicar esfuerzos a mejorar el rendimiento. Preferiría trabajar en la adopción de la solicitud de transmisión (consulte el n. ° 1357) a otros controladores que no sean el controlador de proxy.

buffering large amount of data is a secondary strategy es el punto.
Supongo que el programa rara vez cae en mktemps + fallocate + mmap .

solicitud de transmisión manejada por un controlador que no necesita grandes búferes, ¿verdad?

En mi opinión, el uso de un recurso mmap compartido o privado (incluso como marcador de posición de carga temporal) es una mala idea. La ubicación de $ TMP o $ TMPDIR puede ser cualquier cosa en el entorno del usuario, por ejemplo, puede ser HDD ... es solo un paso adicional que un administrador debe recordar. Sin mencionar que las cargas simultáneas de archivos grandes fácilmente crearían presión en la memoria si $ TMP está montado en un disco ram.

Me gusta mucho su sugerencia y dirección para hacer que la solicitud de transmisión funcione con controladores que no son proxy. ¡Mirando hacia adelante y listo para probar!

¿Fue útil esta página
0 / 5 - 0 calificaciones