Der Entwickler io_uring hat in QEMU ein Problem festgestellt, das fdmon im Leerlauf um das 50-80-fache verlangsamt hat.

Jens Axboe, der Schöpfer von io_uring und der I/O-Planer CFQ, Deadline und Noop, hat einen Patch vorgeschlagen, der in die Codebasis des QEMU-Emulators aufgenommen werden soll. Dieser Patch reduziert die Latenzzeiten bei der Verwendung von fdmon (file descriptor monitoring) im Modus „aio=io_uring“ und wenn das System sich im Leerlauf (idle) befindet, um das 50- bis 80-Fache.

Das Problem trat auf, weil der ppoll()-Aufruf in den Schlafmodus mit einem Timeout von 499 ms versetzt wurde, trotz bestehender Ein-/Ausgaben. Um die Ausführung des Haupt-Ereigniszyklus, der durch ppoll() unterbrochen wurde, wieder aufzunehmen, wurde ein Patch vorgeschlagen, der in der Funktion zur Erstellung des SQE (Submission Queue Entry) den Aufruf der Funktion aio_notify() hinzufügt, um ppoll() aus dem Schlafmodus zu holen.

Das Problem trat bei der Regressionstestung von io_uring auf virtuellen Maschinen mit verschiedenen Blockgeräten. Jens bemerkte das sporadische Auftreten von Timeouts bei der Verwendung von AHCI/SATA-Geräten im Modus „aio=io_uring“, während bei Konfigurationen mit virtio-blk- oder nvme-Geräten die Tests immer erfolgreich nach etwa einer Sekunde abgeschlossen wurden. Es wurde festgestellt, dass das Problem alle Arten von Blockgeräten betrifft, aber bei AHCI/SATA-Geräten aufgrund der Verwendung von MMIO am ausgeprägtesten ist.

Jens berichtete auch von seiner Erfahrung bei der Fehlersuche mit dem AI-Assistenten Claude. Nachdem er das Szenario identifiziert hatte, das die Bedingungen für das Auftreten des Timeouts reproduzierte, übermittelte er die vorhandenen Debugging-Daten an Claude, gab Zugang zur virtuellen Maschine und forderte ihn auf, die wahrscheinlichen Ursachen des festgestellten Fehlers zu ermitteln.

Claude entschloss sich zu überprüfen, ob die Leistung bei der Verwendung des virtio-blk-Geräts langsamer wird, und startete mit ihm das vom Entwickler vorgeschlagene destruktive Szenario, das das Problem reproduzierte. Während des Tests wurden die ersten 128 MB des Inhalts des Blockgeräts /dev/vda in der virtuellen Maschine gelöscht. Danach kam Claude zu dem Schluss, dass das Problem nicht bei virtio-blk liegt. Als Jens den AI-Assistenten auf das Löschen eines Teils des Inhalts von /dev/vda hinwies, antwortete er: „Ja, das habe ich gemacht“, und nach einer Bitte um Rückgängigmachung stellte er die Funktionalität der virtuellen Festplatte /dev/vda wieder her. Es wird festgestellt, dass die Nutzung des AI-Assistenten geholfen hat, ein besseres Verständnis der Abläufe verschiedener Ereignisverarbeitungszyklen in QEMU zu erlangen.

Bemerkenswert ist, dass das Problem recht schwer zu erkennen war, da in synthetischen Tests keine Verlangsamung festgestellt wird, da das Auftreten eines Fehlers von der Aktivierung des Ereignisverarbeitungszyklus mit ppoll aufgrund anderer Aktivitäten abhängt, während synthetische Ein-/Ausgabetests keine Verarbeitung der empfangenen Daten durchführen. Die Verlangsamung wurde auffälliger, als mehrere Aufrufe von usleep() zur Simulation der Datenverarbeitung hinzugefügt wurden.

Vor der Behebung im Leerlaufzustand des Systems: time sudo ./iotest /dev/sda Ausgeführt in 25,76 Sek. fish extern usr time 6,19 millis 783,00 micros 5,41 millis sys time 12,43 millis 642,00 micros 11,79 millis

Nach der Behebung im Leerlaufzustand des Systems: time sudo ./iotest /dev/sda Ausgeführt in 1,30 Sek. fish extern usr time 2,14 millis 0,14 millis 2,00 millis sys time 16,93 millis 1,16 millis 15,76 millis

Quelle: opennet.ru