io_uring 和 CFQ、Deadline 和 Noop I/O 调度器的创建者 Jens Axboe 提出了一个补丁，建议将其纳入 QEMU 模拟器代码库中。该补丁在“aio=io_uring”模式下运行 fdmon（文件描述符监控）以及系统空闲时，可将延迟降低 50-80 倍。
问题在于，尽管存在 I/O 操作，ppoll() 操作仍被置于 499 毫秒的超时睡眠模式。为了恢复被 ppoll() 暂停的主事件处理循环的执行，我们提出了一种补丁，该补丁在 SQE（提交队列条目）条目创建函数中添加了对 aio_notify() 函数的调用，从而唤醒 ppoll() 操作。
问题是在对 io_uring 进行回归测试时出现的。 虚拟机 Jens 使用各种块设备进行测试时发现，在使用“aio=io_uring”模式的 AHCI/SATA 设备时偶尔会出现超时，而使用 virtio-blk 或 nvme 设备时，测试总能在大约一秒内成功完成。他指出，这个问题会影响所有类型的块设备，但对于 AHCI/SATA 设备而言，由于使用了 MMIO，延迟最为明显。
Jens还描述了他使用人工智能助手Claude调试问题的经历。在确定了一个可以重现超时情况的场景后，他将可用的调试数据传递给了Claude，授予了它对虚拟机的访问权限，并主动提出找出检测到的故障的可能原因。
克劳德决定测试使用 virtio-blk 设备时性能是否会下降，并运行了开发者提供的破坏性脚本来重现这个问题。测试期间，虚拟机中 /dev/vda 块设备的前 128 MB 内容被删除。之后，克劳德得出结论，virtio-blk 并非问题所在。当詹斯指示 AI 助手删除 /dev/vda 的部分内容时，助手回应“是的，我已执行”，并在詹斯要求其修复后，将 /dev/vda 虚拟磁盘恢复到正常工作状态。使用 AI 助手帮助詹斯更好地理解了 QEMU 各种事件处理循环的具体细节。
值得注意的是，这个问题很难检测，因为在合成测试中无法检测到性能下降，这是因为崩溃是由 ppoll 事件循环因其他活动而被唤醒触发的，而合成 I/O 测试并不处理接收到的数据。当添加多个 usleep() 调用来模拟数据处理时，性能下降变得更加明显。
在系统处于空闲状态之前：执行 sudo ./iotest /dev/sda 命令耗时 25.76 秒，fish 外部用户耗时 6.19 毫秒，783.00 微秒，5.41 毫秒；系统耗时 12.43 毫秒，642.00 微秒，11.79 毫秒。
问题修复后，在空闲系统上执行以下命令：`sudo ./iotest /dev/sda` 执行时间为 1.30 秒；fish 外部用户时间 2.14 毫秒；0.14 毫秒；2.00 毫秒；系统时间 16.93 毫秒；1.16 毫秒；15.76 毫秒。
来源： opennet.ru
