https://bugzilla.kernel.org/show_bug.cgi?id=199727 --- Comment #8 from Roland Kletzing (devzero@xxxxxx) --- yes. i found the following interesting information. i think this explains a LOT. https://docs.openeuler.org/en/docs/20.03_LTS/docs/Virtualization/best-practices.html#i-o-thread-configuration I/O Thread Configuration Overview By default, QEMU main threads handle backend VM read and write operations on the KVM. This causes the following issues: VM I/O requests are processed by a QEMU main thread. Therefore, the single-thread CPU usage becomes the bottleneck of VM I/O performance. The QEMU global lock (qemu_global_mutex) is used when VM I/O requests are processed by the QEMU main thread. If the I/O processing takes a long time, the QEMU main thread will occupy the global lock for a long time. As a result, the VM vCPU cannot be scheduled properly, affecting the overall VM performance and user experience. You can configure the I/O thread attribute for the virtio-blk disk or virtio-scsi controller. At the QEMU backend, an I/O thread is used to process read and write requests of a virtual disk. The mapping relationship between the I/O thread and the virtio-blk disk or virtio-scsi controller can be a one-to-one relationship to minimize the impact on the QEMU main thread, enhance the overall I/O performance of the VM, and improve user experience. Configu -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
