Am 13.02.2025 um 19:00 hat Stefan Hajnoczi geschrieben: > Allow virtio-scsi virtqueues to be assigned to different IOThreads. This > makes it possible to take advantage of host multi-queue block layer > scalability by assigning virtqueues that have affinity with vCPUs to > different IOThreads that have affinity with host CPUs. The same feature > was introduced for virtio-blk in the past: > https://developers.redhat.com/articles/2024/09/05/scaling-virtio-blk-disk-io-iothread-virtqueue-mapping > > Here are fio randread 4k iodepth=64 results from a 4 vCPU guest with an > Intel P4800X SSD: > iothreads IOPS > ------------------------------ > 1 189576 > 2 312698 > 4 346744 > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
As Peter already noted, the interface is a bit confusing in that it considers the control and event queue just normal queues like any other and you need to specify a mapping for them, too (even though you probably don't care about them). I wonder if it wouldn't be better to use the iothread-vq-mapping property only for command queues and to have separate properties for the event and control queue. I think this would be less surprising to users. It would also allow you to use the round robin allocation for command queues while using a different setting for the special queues - in particular, the event queue is currently no_poll, which disables polling for the whole AioContext, so you probably want to have it just anywhere else, but not in the iothreads you use for command queues. This should probably also be the default. Kevin
