On 26.07.2022 16:45, Michael S. Tsirkin wrote:
On Mon, Jul 25, 2022 at 11:27:53PM +0300, Andrey Zhadchenko wrote:Although QEMU virtio is quite fast, there is still some room for improvements. Disk latency can be reduced if we handle virito-blk requests in host kernel istead of passing them to QEMU. The patch adds vhost-blk kernel module to do so. Some test setups: fio --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=128 QEMU drive options: cache=none filesystem: xfs SSD: | randread, IOPS | randwrite, IOPS | Host | 95.8k | 85.3k | QEMU virtio | 57.5k | 79.4k | QEMU vhost-blk | 95.6k | 84.3k | RAMDISK (vq == vcpu): | randread, IOPS | randwrite, IOPS | virtio, 1vcpu | 123k | 129k | virtio, 2vcpu | 253k (??) | 250k (??) | virtio, 4vcpu | 158k | 154k | vhost-blk, 1vcpu | 110k | 113k | vhost-blk, 2vcpu | 247k | 252k | vhost-blk, 4vcpu | 576k | 567k | Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@xxxxxxxxxxxxx>Sounds good to me. What this depends on is whether some userspace will actually use it. In the past QEMU rejected support for vhost-blk, if this time it fares better then I won't have a problem merging the kernel bits.
In general, we are going to use this in production for our next generation product and thus we would be very glad to see both parts, i.e. in-kernel and in-QEMU to be merged to reduce our support costs. I think that numbers are talking on themselves and this would be quite beneficial for all parties especially keeping in mind that QCOW2 is also now supported for this kind of IO engine. Den
