Jens Axboe, creatore di io_uring e dei pianificatori di input/output CFQ, Deadline e Noop, ha proposto l'inclusione di un patch nel codice sorgente dell'emulatore QEMU che riduce le latenze durante il lavoro con fdmon (file descriptor monitoring) in modalità «aio=io_uring» fino a 50-80 volte quando la macchina è in stato di inattività.
Il problema si manifestava a causa della traduzione dell'operazione ppoll() in uno stato di sleep con un timeout di 499 ms, nonostante la presenza di input/output. Per riprendere l'esecuzione del ciclo principale di gestione degli eventi, sospeso a causa di ppoll(), è stata proposta una patch che aggiunge una chiamata alla funzione aio_notify() nella funzione di creazione della voce SQE (Submission Queue Entry), per sbloccare ppoll() dallo stato di sleep.
Il problema è emerso durante i test di regressione di io_uring in macchine virtuali con diversi dispositivi a blocchi. Jens ha notato l'apparizione casuale di timeout nell'uso di dispositivi AHCI/SATA in modalità «aio=io_uring», mentre nei test con dispositivi virtio-blk o nvme, le prove concluono sempre con successo in circa un secondo. Si osserva che il problema riguarda tutti i tipi di dispositivi a blocchi, ma per i dispositivi AHCI/SATA l'insorgenza di latenze è particolarmente pronunciata a causa dell'uso di MMIO.
Jens ha anche descritto la sua esperienza di debugging del problema utilizzando l'assistente AI Claude. Dopo aver identificato lo scenario che riproduceva le condizioni per l'insorgenza del timeout, ha fornito i dati di debug a Claude, ha concesso accesso alla macchina virtuale e ha suggerito di identificare le probabili cause del guasto riscontrato.
Claude ha deciso di verificare se le prestazioni si sarebbero rallentate utilizzando il dispositivo virtio-blk e ha eseguito lo scenario distruttivo proposto dallo sviluppatore, che riproduceva il problema. Durante il test, i primi 128 MB di contenuto del dispositivo a blocchi /dev/vda nella macchina virtuale sono stati rimossi. Successivamente, Claude ha concluso che il problema non era nel virtio-blk. Quando Jens ha fatto notare all'assistente AI la rimozione di parte del contenuto di /dev/vda, ha risposto "Sì, l'ho fatto" e, dopo la richiesta di ripristino, ha ripristinato il funzionamento del disco virtuale /dev/vda. È stato notato che l'uso dell'assistente AI ha aiutato a comprendere meglio le caratteristiche dell'esecuzione dei diversi cicli di elaborazione degli eventi in QEMU.
È notevole che il problema sia stato piuttosto difficile da identificare, poiché nei test sintetici non si rileva alcun rallentamento a causa del risveglio del ciclo di eventi con ppoll da attività diverse, e i test sintetici di input/output non elaborano i dati ricevuti. Il rallentamento è diventato più evidente con l'aggiunta di diverse chiamate a usleep() per simulare l'elaborazione dei dati.
Prima della correzione, sul sistema in stato di inattività: time sudo ./iotest /dev/sda Eseguito in 25.76 secs fish esterno usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis
Dopo la correzione, sul sistema in stato di inattività: time sudo ./iotest /dev/sda Eseguito in 1.30 secs fish esterno usr time 2.14 millis 0.14 millis 2.00 millis sys time 16.93 millis 1.16 millis 15.76 millis
Fonte: opennet.ru
