Der Entwickler von io_uring hat ein Problem in QEMU identifiziert, das fdmon im Leerlauf 50-80 Mal verlangsamt hat.

Jens Axboe, der Schöpfer von io_uring sowie der I/O-Planer CFQ, Deadline und Noop, hat einen Patch vorgeschlagen, der in die Codebasis des QEMU-Emulators integriert werden soll. Dieser Patch reduziert die Latenzen bei der Arbeit mit fdmon (File Descriptor Monitoring) im Modus „aio=io_uring“ und im Leerlauf (Idle) um das 50-80-Fache.

Das Problem trat auf, weil die ppoll()-Operation in den Schlafzustand mit einem Timeout von 499 ms versetzt wurde, trotz vorhandener Ein-/Ausgabe. Um den Hauptverarbeitungsschleifen, die aufgrund von ppoll() angehalten wurden, wiederaufzunehmen, wurde ein Patch vorgeschlagen, der in die SQE (Submission Queue Entry)-Erstellungsfunktion den Aufruf der Funktion aio_notify() integriert, wodurch ppoll() aus dem Schlafmodus geholt wird.

Das Problem trat beim Regressionstest von io_uring auf virtuellen Maschinen wurde vereinfacht. 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 die Tests in Konfigurationen mit virtio-blk- oder nvme-Geräten immer erfolgreich innerhalb von etwa einer Sekunde abgeschlossen wurden. Dabei wird festgestellt, dass das Problem alle Arten von Blockgeräten betrifft, aber bei AHCI/SATA-Geräten die Verzögerungen am stärksten ausgeprägt sind, bedingt durch die Verwendung von MMIO.

Jens hat auch seine Erfahrung bei der Fehlersuche mit dem AI-Assistenten Claude beschrieben. Nachdem er das Szenario definiert hatte, das die Bedingungen für den Timeout reproduzierte, übermittelte er die vorhandenen Debug-Daten an Claude, gewährte Zugang zur virtuellen Maschine und schlug vor, die möglichen Ursachen des identifizierten Fehlers zu ermitteln.

Claude entschloss sich zu überprüfen, ob sich die Leistung bei Verwendung des Geräts virtio-blk verlangsamt, und startete 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 stellte Claude fest, dass das Problem nicht bei virtio-blk lag. Als Jens den AI-Assistenten auf das Löschen eines Teils des Inhalts von /dev/vda hinwies, antwortete er: „Ja, ich habe das gemacht“, und nach der Bitte um Wiederherstellung — stellte er die Funktionalität des virtuellen Laufwerks /dev/vda wieder her. Es wird erwähnt, dass die Nutzung des AI-Assistenten half, die Abläufe verschiedener Ereignisschleifen in QEMU besser zu verstehen.

Es ist bemerkenswert, dass das Problem schwer zu erkennen war, da die Verlangsamung in synthetischen Tests nicht erfasst wird. Dies geschieht, weil das Auftreten des Fehlers durch das Erwachen des Event-Processing-Cycles mit ppoll aufgrund anderer Aktivitäten beeinflusst wird und synthetische Eingabe-/Ausgabetests die empfangenen Daten nicht verarbeiten. Die Verlangsamung wurde deutlicher, als mehrere Aufrufe von usleep() hinzugefügt wurden, um die Datenverarbeitung zu simulieren.

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

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

Quelle: opennet.ru