Jens Axboe, creador de io_uring y de los planificadores de entrada/salida CFQ, Deadline y Noop, ha propuesto incluir en la base de código del emulador QEMU un parche que reduce las latencias entre 50 y 80 veces al trabajar con fdmon (monitorización de descriptores de fichero) en modo «aio=io_uring» y cuando el sistema está en estado de inactividad.
El problema se manifestaba debido a la conversión de la operación ppoll() en un estado de sueño con un tiempo de espera de 499 ms, a pesar de que había actividad de entrada/salida. Para reanudar la ejecución del bucle principal de procesamiento de eventos, que se suspendía debido a ppoll(), se ha propuesto un parche que añade en la función de creación de la entrada en la cola de envío (SQE - Submission Queue Entry) una llamada a la función aio_notify(), que saca a ppoll() del estado de sueño.
El problema surgió durante las pruebas de regresión de io_uring en máquinas virtuales diferentes dispositivos de bloque. Jens notó la aparición aleatoria de tiempos de espera al utilizar dispositivos AHCI/SATA en modo «aio=io_uring», mientras que en configuraciones con dispositivos virtio-blk o nvme, las pruebas siempre se completaban exitosamente en aproximadamente un segundo. Se observa que el problema afecta a todos los tipos de dispositivos de bloque, pero en el caso de dispositivos AHCI/SATA, la aparición de retrasos es más pronunciada debido al uso de MMIO.
Jens también describió su experiencia depurando el problema utilizando el asistente de IA Claude. Después de identificar un escenario que reproducía las condiciones para que se produjera un tiempo de espera, entregó los datos de depuración a Claude, proporcionó acceso a la máquina virtual y sugirió identificar las posibles causas del fallo detectado.
Claude decidió verificar si el rendimiento se vería afectado al utilizar un dispositivo virtio-blk y ejecutó con él el escenario destructivo propuesto por el desarrollador que reproduce el problema. Durante la comprobación, se eliminaron los primeros 128 MB de contenido del dispositivo de bloque /dev/vda en la máquina virtual. Después de esto, Claude concluyó que el problema no estaba en virtio-blk. Cuando Jens señaló al asistente de IA la eliminación de parte del contenido de /dev/vda, este respondió «Sí, lo hice», y tras solicitarle que lo reparara, restauró el funcionamiento del disco virtual /dev/vda. Se destaca que el uso del asistente de IA ayudó a comprender mejor las particularidades de la ejecución de los diferentes ciclos de procesamiento de eventos en QEMU.
Es notable que el problema fue bastante difícil de detectar, ya que en las pruebas sintéticas la ralentización no se registra debido a que la aparición del fallo depende del despertar del ciclo de procesamiento de eventos con ppoll por otra actividad, y las pruebas sintéticas de entrada/salida no procesan los datos recibidos. La ralentización se volvió más evidente al agregar varias llamadas a usleep() para simular el procesamiento de datos.
Antes de la corrección en el sistema en estado de inactividad (idle): time sudo ./iotest /dev/sda Ejecutado en 25.76 segs fish externo usr time 6.19 milisegundos 783.00 micros 5.41 milisegundos sys time 12.43 milisegundos 642.00 micros 11.79 milisegundos
Después de la corrección en el sistema en estado de inactividad: time sudo ./iotest /dev/sda Ejecutado en 1.30 segs fish externo usr time 2.14 milisegundos 0.14 milisegundos 2.00 milisegundos sys time 16.93 milisegundos 1.16 milisegundos 15.76 milisegundos
Fuente: opennet.ru
