¿Cuál es el progreso con respecto a la mejora del rendimiento / capacidad de respuesta del sistema durante una alta E / S de disco?

Cada vez que hay una E / S de disco alta, el sistema tiende a ser mucho más lento y responde menos de lo habitual. ¿Cuál es el progreso en el kernel de Linux con respecto a esto? ¿Se está trabajando activamente en este problema?

Creo que en su mayor parte se ha resuelto. Mi rendimiento bajo IO pesado ha mejorado en 2.6.36 y espero que mejore más en 2.6.37. Vea estos artículos de phoronix .

Wu Fengguang y KOSAKI Motohiro han publicado parches esta semana que creen que abordarán algunos de estos problemas de capacidad de respuesta, por lo que dicen que el "sistema deja de responder bajo presión de memoria y muchas páginas sucias / reescritas". Andreas Mohr, uno de los usuarios que reportó este problema al LKML y probó los dos parches que se aplican contra el vmscan del kernel, reportó éxito. El problema de Andreas era que el sistema dejaba de responder (y cambiar a un VT tardó más de 20 segundos) al hacer un sistema de archivos EXT4 cuando se conectaba una unidad de estado sólido a través de USB 1.1. En su sistema, al escribir 300M desde el archivo / dev / zero, el problema era aún peor.

Aquí hay un enlace directo al error

También de Phoronix

Afortunadamente, a partir de nuestras pruebas y los informes de otros usuarios de Linux que buscan corregir este problema, los parches vmscan relativamente pequeños que se publicaron parecen abordar mejor el problema. La interfaz de usuario (GNOME en nuestro caso) todavía no es 100% fluida si el sistema mantiene una cantidad abrumadora de actividad de disco, pero ciertamente es mucho mejor que antes y lo que se encuentra ahora mismo con el kernel Linux 2.6.35.

También está el anuncio de lanzamiento de Phoronix 2.6.36

Parece que las barreras de bloqueo están desapareciendo y eso también debería ayudar al rendimiento.

En la práctica, las barreras tienen una reputación desagradable por matar el rendimiento de E / S de bloque, hasta el punto de que los administradores a menudo se ven tentados a apagarlas y asumir sus riesgos. Si bien las operaciones de cola etiquetadas proporcionadas por el hardware contemporáneo deberían implementar barreras razonablemente bien, los intentos de hacer uso de esas características generalmente han tenido dificultades. Por lo tanto, en el mundo real, las barreras se implementan simplemente drenando la cola de solicitud de E / S antes de emitir la operación de barrera, con algunas operaciones de descarga para lograr que el hardware realmente envíe los datos a medios persistentes. Las operaciones de drenaje de cola detendrán el dispositivo y eliminarán el paralelismo necesario para un rendimiento completo; No es sorprendente que el uso de barreras pueda ser doloroso.

También hay este artículo de LWN sobre la programación justa de E / S

Yo diría que IO volvió a despertar como un gran problema sobre el momento del lanzamiento de ext4 en 2.6.28. Los siguientes enlaces son para Linux Kernel Newbies Kernel, debe revisar las secciones Bloque y Sistemas de archivos. Esto, por supuesto, puede ser un sentimiento injusto, o solo el momento en que comencé a ver el desarrollo de FS, estoy seguro de que ha estado mejorando todo el tiempo, pero siento que algunos de los problemas ext4 causaron que la gente mirara con atención la pila de E / S, o podría ser que esperaban que ext4 resolviera todos los problemas de rendimiento, y luego, cuando no fue así, se dieron cuenta de que tenían que buscar los problemas en otra parte.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37