Jens Axboe, tvůrce io_uring a plánovačů vstupu/výstupu CFQ, Deadline a Noop, navrhl pro zařazení do kódové základny emulátoru QEMU patch, který snižuje latenci při práci s fdmon (monitorování deskriptorů souborů) v režimu „aio=io_uring“ a když je systém v nečinnosti (idle) o 50-80 %.
Problém se projevoval při převodu operace ppoll() do stavu spánku s časovým limitem 499 ms, i když byl k dispozici vstup/výstup. Pro obnovení hlavního zpracovatelského cyklu, který byl pozastaven kvůli ppoll(), byl navržen patch, který přidává do funkce pro vytváření záznamu SQE (Submission Queue Entry) volání funkce aio_notify(), která probudí ppoll() ze stavu spánku.
Problém se objevil při regresním testování io_uring s virtual machines různými blokovými zařízeními. Jens si všiml náhodného výskytu časových limitů při používání AHCI/SATA zařízení v režimu „aio=io_uring“, zatímco v konfiguracích s zařízeními virtio-blk nebo nvme testy vždy úspěšně skončily zhruba za sekundu. Je také poznamenáno, že problém se dotýká všech typů blokových zařízení, avšak u zařízení AHCI/SATA se projevuje nejvýrazněji kvůli použití MMIO.
Jens také popsal svou zkušenost s laděním problému pomocí AI asistenta Claude. Po určení scénáře, který reprodukoval podmínky vedoucí k výskytu časového limitu, předal dostupné ladicí údaje Claudovi, poskytl přístup k virtuálnímu počítači a navrhl, aby určil pravděpodobné příčiny zjištěné chyby.
Claude se rozhodl zkontrolovat, zda se výkon zpomalí při používání zařízení virtio-blk, a spustil s ním navrhovaný destruktivní scénář, který reprodukoval problém. Během kontroly byly odstraněny první 128 MB obsahu z blokového zařízení /dev/vda ve virtuálním počítači. Poté Claude usoudil, že problém není v virtio-blk. Když Jens upozornil AI asistenta na odstranění části obsahu /dev/vda, odpověděl: „Ano, udělal jsem to“, a po žádosti o opravu obnovil funkčnost virtuálního disku /dev/vda. Je poznamenáno, že použití AI asistenta pomohlo lépe pochopit vlastnosti vykonávání různých cyklů zpracování událostí v QEMU.
Je pozoruhodné, že problém bylo obtížné odhalit, protože ve syntetických testech se zpomalení nepotvrzuje, jelikož na výskyt chyby má vliv probuzení cyklu zpracování událostí pomocí ppoll kvůli jiné aktivitě, a syntetické testy vstupu/výstupu nezpracovávají přijatá data. Zpomalení se stalo výraznější při přidání několika volání usleep() pro simulaci zpracování dat.
Před opravou na systému v nečinném stavu (idle): time sudo ./iotest /dev/sda Provedeno za 25.76 sekundy fish externí usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis
Po opravě na systému v nečinném stavu: time sudo ./iotest /dev/sda Provedeno za 1.30 sekundy fish externí usr time 2.14 millis 0.14 millis 2.00 millis sys time 16.93 millis 1.16 millis 15.76 millis
Zdroj: opennet.ru
