Разработчик io_uring выявил в QEMU проблему, в 50-80 раз замедлявшую fdmon в режиме простоя

Новости мира unix. Хотите узнать секрет вечного счастья? Откройте страницу 246.
Ответить
acolyte
Аватара пользователя
Сообщения: 1065
Зарегистрирован: 20.08.2022

#

Разработчик io_uring выявил в QEMU проблему, в 50-80 раз замедлявшую fdmon в режиме простоя
Дата публикации:Fri, 20 Feb 2026 11:49:49 +0300

Йенс Эксбо (Jens Axboe), создатель io_uring и планировщиков ввода/вывода CFQ, Deadline и Noop, предложил для включения в кодовую базу эмулятора QEMU патч, в 50-80 раз сокращающий задержки в fdmon (file descriptor monitoring) в режиме "aio=io_uring" при нахождении системы в состоянии простоя (iddle).
Проблема проявлялась из-за перевода операции ppoll() в состоянии сна с таймаутом 499 мс, несмотря на наличие ввода/вывода. Для возобновления выполнения основного цикла обработки событий, приостанавливаемого из-за ppoll(), предложен патч, добавляет в функцию создания записи SQE (Submission Queue Entry) вызов функции aio_notify(), выводящий ppoll() из режима сна.
Проблема всплыла при регрессионном тестировании io_uring в виртуальных машинах c разными блочными устройствами. Йенс обратил внимание на случайное появление таймаутов при использовании AHCI/SATA-устройств в режиме "aio=io_uring", в то время как в конфигурациях с устройствами virtio-blk или nvme тесты всегда успешно завершались примерно за секунду. При этом отмечается, что проблема затрагивает все типы блочных устройств, но для устройств AHCI/SATA появление задержек наиболее ярко выражено из-за использования MMIO.
Йенс также описал свой опыт отладки проблемы с использованием AI-ассистента Claude. После определения сценария, воспроизводящего условия для возникновения таймаута, он передал имеющиеся отладочные данные Claude, предоставил доступ к виртуальной машине и предложил определить вероятные причины выявленного сбоя.
Claude решил проверить замедлится ли работа при использовании устройства virtio-blk и запустил с ним предложенный разработчиком деструктивный сценарий, воспроизводящий проблему. В ходе выполнения проверки были удалены первые 128 МБ содержимого из блочного устройства /dev/vda в виртуальной машине. После этого, Claud сделал вывод, что проблема не в virtio-blk. Когда Йенс указал AI-ассистенту на удаление части содержимого /dev/vda, он ответил "Да, я сделал это", а после просьбы исправить - восстановил работоспособность виртуального диска /dev/vda. Отмечается, что использование AI-ассистента помогло лучше понять особенности выполнения различных циклов обработки событий в QEMU.
Примечательно, что проблему было достаточно трудно обнаружить, так как в синтетических тестах замедление не фиксируется из-за того, что на возникновение сбоя влияет пробуждение цикла обработки событий с ppoll из-за другой активности, а синтетические тесты ввода/вывода не выполняют обработку полученных данных. Замедление стало более заметным при добавлении нескольких вызовов usleep() для симуляции обработки данных.
До исправления на системе в состоянии простоя (iddle):
time sudo ./iotest /dev/sda Executed in 25.76 secs fish external usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis После исправления на системе в состоянии простоя:
time sudo ./iotest /dev/sda Executed in 1.30 secs fish external usr time 2.14 millis 0.14 millis 2.00 millis sys time 16.93 millis 1.16 millis 15.76 millis

Новость позаимствована с opennet.ru
Ссылка на оригинал: https://www.opennet.ru/opennews/art.shtml?num=64834

Жизнь за Нер'зула!

Ответить