Jens Axboe, twórca io_uring oraz planistów I/O CFQ, Deadline i Noop, zaproponował dołączenie do bazy kodu emulatora QEMU łatki, która 50-80 razy zmniejsza opóźnienia przy pracy fdmon (monitoring deskryptora pliku) w trybie „aio=io_uring” i w przypadku systemu będącego w stanie bezczynności.
Problem wynikał z przeniesienia operacji ppoll() w stan uśpienia z timeoutem 499 ms, mimo że były dostępne dane I/O. Aby wznowić wykonanie głównej pętli przetwarzania zdarzeń, wstrzymanej z powodu ppoll(), zaproponowano łatkę, która dodaje do funkcji tworzenia wpisu SQE (Submission Queue Entry) wywołanie funkcji aio_notify(), która wybudza ppoll() z trybu uśpienia.
Problem pojawił się podczas testów regresyjnych io_uring w maszynach wirtualnych różnych urządzeniach blokowych. Jens zauważył przypadkowe występowanie timeoutów przy używaniu urządzeń AHCI/SATA w trybie „aio=io_uring”, podczas gdy w konfiguracjach z urządzeniami virtio-blk lub nvme testy zawsze kończyły się pomyślnie w ciągu około sekundy. Warto zauważyć, że problem dotyczy wszystkich typów urządzeń blokowych, ale dla urządzeń AHCI/SATA opóźnienia są najbardziej wyraźne z powodu użycia MMIO.
Jens również opisał swoje doświadczenie w debugowaniu problemu z użyciem asystenta AI Claude. Po zidentyfikowaniu scenariusza, który odtwarzał warunki do wystąpienia timeoutu, przekazał dostępne dane debugowania Claude, dał dostęp do maszyny wirtualnej i zaproponował określenie prawdopodobnych przyczyn ujawnionego błędu.
Claude postanowił sprawdzić, czy wydajność spadnie przy użyciu urządzenia virtio-blk i uruchomił z nim proponowany przez dewelopera destrukcyjny scenariusz, reprodukujący problem. W trakcie testu usunięto pierwsze 128 MB zawartości z urządzenia blokowego /dev/vda w maszynie wirtualnej. Następnie Claude doszedł do wniosku, że problem nie leży w virtio-blk. Gdy Jens wskazał asystentowi AI na usunięcie części zawartości /dev/vda, odpowiedział „Tak, zrobiłem to”, a po prośbie o naprawę - przywrócił funkcjonalność wirtualnego dysku /dev/vda. Zauważono, że użycie asystenta AI pomogło lepiej zrozumieć aspekty wykonania różnych cykli przetwarzania zdarzeń w QEMU.
Warto zauważyć, że problem był dość trudny do wykrycia, ponieważ w testach syntetycznych opóźnienie nie jest rejestrowane z powodu wpłynięcia na wystąpienie błędu przez obudzenie cyklu przetwarzania zdarzeń z ppoll w wyniku innej aktywności, a syntetyczne testy wejścia/wyjścia nie wykonują przetwarzania otrzymanych danych. Opóźnienie stało się bardziej zauważalne po dodaniu kilku wywołań usleep() w celu symulacji przetwarzania danych.
Po naprawie na systemie w stanie spoczynku (idle): time sudo ./iotest /dev/sda Wykonano w 25.76 sekundy fish zewnętrzny usr czas 6.19 millis 783.00 micros 5.41 millis sys czas 12.43 millis 642.00 micros 11.79 millis
Po naprawie na systemie w stanie spoczynku: time sudo ./iotest /dev/sda Wykonano w 1.30 sekundy fish zewnętrzny usr czas 2.14 millis 0.14 millis 2.00 millis sys czas 16.93 millis 1.16 millis 15.76 millis
Źródło: opennet.ru
