Разработчик io_uring разкри проблема в QEMU, която забавя fdmon в режим на покой от 50 до 80 пъти.

Йенс Екбо (Jens Axboe), създателят на io_uring и планировачите за вход/изход CFQ, Deadline и Noop, предложи за включване в кода на емулатора QEMU патч, който намалява закъсненията при работа fdmon (file descriptor monitoring) в режим «aio=io_uring» и при състояние на празен режим (idle) между 50 и 80 пъти.

Проблемът се прояви поради преминаването на операцията ppoll() в режим на сън с таймаут от 499 ms, въпреки наличието на вход/изход. За възобновяване на основния цикъл на обработка на събития, спрян заради ppoll(), предложен е патч, който добавя в функцията за създаване на запис SQE (Submission Queue Entry) извикване на функцията aio_notify(), която изкарва ppoll() от състояние на сън.

Проблемът се появи при регресионно тестване на io_uring в виртуални машини различни блочни устройства. Йенс обърна внимание на случайното появяване на таймаути при използване на AHCI/SATA устройства в режим «aio=io_uring», докато в конфигурации с устройства virtio-blk или nvme тестовете приключваха успешно за около секунда. Важно е да се отбележи, че проблемът засяга всички типове блочни устройства, но приAHCI/SATA устройствата забавянията са най-изразени поради използването на MMIO.

Йенс също така описа опита си с отстраняване на проблеми, използвайки AI асистента Claude. След определяне на сценария, който възпроизвежда условията за възникване на таймаут, той предостави наличните отладъчни данни на Claude, осигури достъп до виртуалната машина и предложи да се определят вероятните причини за установения проблем.

Claude реши да провери дали работата ще се забави при използване на устройството virtio-blk и стартира предложен от разработчика деструктивен сценарий, който възпроизвежда проблема. По време на проверката бяха изтрити първите 128 MB съдържание от блочното устройство /dev/vda във виртуалната машина. След това Claude заключи, че проблемът не е в virtio-blk. Когато Йенс посочи на AI асистента изтриването на част от съдържанието на /dev/vda, той отговори «Да, направих го», а след молба за поправка — възстанови работоспособността на виртуалния диск /dev/vda. Забелязва се, че използването на AI асистента помогна за по-добро разбиране на особеностите на изпълнението на различните цикли на обработка на събития в QEMU.

Забележително е, че проблемът беше достатъчно труден за откриване, тъй като в синтетичните тестове забавянето не се фиксира поради факта, че за възникването на сбоя влияе събуждането на цикъла за обработка на събития с ppoll заради друга активност, а синтетичните тестове за вход/изход не извършват обработка на получените данни. Забавянето стана по-забележимо при добавянето на няколко повиквания на usleep() за симулиране на обработката на данни.

Преди корекцията на системата в състояние на покой (idle): time sudo ./iotest /dev/sda Изпълнено за 25.76 сек fish външно usr време 6.19 милисек 783.00 микро 5.41 милисек sys време 12.43 милисек 642.00 микро 11.79 милисек

След корекцията на системата в състояние на покой: time sudo ./iotest /dev/sda Изпълнено за 1.30 сек fish външно usr време 2.14 милисек 0.14 милисек 2.00 милисек sys време 16.93 милисек 1.16 милисек 15.76 милисек

Източник: opennet.ru

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster