Jens Axboe, il creatore di io_uring e degli scheduler I/O CFQ, Deadline e Noop, ha proposto una patch da includere nel codice base dell'emulatore QEMU che riduce la latenza di un fattore 50-80 quando si esegue fdmon (monitoraggio dei descrittori di file) in modalità "aio=io_uring" e quando il sistema è inattivo.
Il problema era causato dall'operazione ppoll() messa in modalità sleep con un timeout di 499 ms, nonostante la presenza di I/O. Per riprendere l'esecuzione del ciclo di elaborazione dell'evento principale sospeso da ppoll(), è stata proposta una patch che aggiunge una chiamata alla funzione aio_notify() alla funzione di creazione delle voci SQE (Submission Queue Entry), riattivando ppoll() dalla modalità sleep.
Il problema è emerso durante i test di regressione di io_uring in macchine virtuali Con vari dispositivi a blocchi, Jens ha notato dei timeout occasionali quando si utilizzavano dispositivi AHCI/SATA in modalità "aio=io_uring", mentre i test si completavano sempre con successo in circa un secondo con dispositivi virtio-blk o nvme. Ha osservato che il problema riguarda tutti i tipi di dispositivi a blocchi, ma per i dispositivi AHCI/SATA i ritardi sono più pronunciati a causa dell'utilizzo di MMIO.
Jens ha anche descritto la sua esperienza nel debug del problema utilizzando l'assistente AI Claude. Dopo aver identificato uno scenario che riproduceva le condizioni di timeout, ha trasmesso i dati di debug disponibili a Claude, ha concesso l'accesso alla macchina virtuale e si è offerto di identificare le probabili cause dell'errore rilevato.
Claude decise di verificare se le prestazioni sarebbero diminuite utilizzando il dispositivo virtio-blk ed eseguì lo script distruttivo dello sviluppatore per riprodurre il problema. Durante il test, i primi 128 MB di contenuto furono eliminati dal dispositivo a blocchi /dev/vda nella macchina virtuale. Dopodiché, Claude concluse che il problema non era virtio-blk. Quando Jens ordinò all'assistente AI di eliminare parte del contenuto di /dev/vda, quest'ultimo rispose "Sì, l'ho fatto" e, dopo avergli chiesto di risolvere il problema, ripristinò il disco virtuale /dev/vda. L'utilizzo dell'assistente AI lo aiutò a comprendere meglio le specifiche dei vari cicli di elaborazione degli eventi di QEMU.
In particolare, il problema è stato piuttosto difficile da rilevare, poiché il rallentamento non viene rilevato nei test sintetici, in quanto l'arresto anomalo è innescato dal riavvio del loop di eventi ppoll a causa di altre attività e i test di I/O sintetici non elaborano i dati ricevuti. Il rallentamento è diventato più evidente aggiungendo più chiamate usleep() per simulare l'elaborazione dei dati.
Prima di ripristinare il sistema in stato di inattività: time sudo ./iotest /dev/sda Eseguito in 25.76 secondi fish external usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis
Dopo aver risolto il problema, su un sistema inattivo: time sudo ./iotest /dev/sda Eseguito in 1.30 secondi fish external 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
