mbox series

[00/12] virtio-scsi: add iothread-vq-mapping parameter

Message ID 20250213180043.713434-1-stefanha@redhat.com (mailing list archive)
Headers show
Series virtio-scsi: add iothread-vq-mapping parameter | expand

Message

Stefan Hajnoczi Feb. 13, 2025, 6 p.m. UTC
Implement --device virtio-scsi-pci,iothread-vq-mapping= support so that
virtqueues can be assigned to different IOThreads. This improves SMP guest
scalability where I/O-intensive applications can become bottlenecked on a
single IOThread.

The following benchmark results show the effect of iothread-vq-mapping. fio
randread 4k iodepth=64 results from a 4 vCPU guest with an Intel P4800X SSD:
iothreads IOPS
------------------------------
1         189576
2         312698
4         346744

The virtio-scsi device model and core SCSI emulation currently assume that
requests are processed in a single AioContext. This patch series goes about
modifying this as follows:

scsi-disk: drop unused SCSIDiskState->bh field
dma: use current AioContext for dma_blk_io()

Make dma-helpers.c support the QEMU multi-queue block layer by using
qemu_get_current_aio_context().

scsi: track per-SCSIRequest AioContext
scsi: introduce requests_lock

Make the core SCSI emulation code support processing requests in multiple
AioContexts by protecting the per-SCSIDevice requests list.

virtio-scsi: introduce event and ctrl virtqueue locks
virtio-scsi: protect events_dropped field
virtio-scsi: perform TMFs in appropriate AioContexts

Make the virtio-scsi emulation code support processing requests in multiple
AioContexts. The event and ctrl virtqueues can interact with multiple
AioContexts. Especially the SCSI Task Management Functions (TMFs) handled by
the ctrl virtqueue need to be made thread-safe.

virtio-blk: extract cleanup_iothread_vq_mapping() function
virtio-blk: tidy up iothread_vq_mapping functions
virtio: extract iothread-vq-mapping.h API
virtio-scsi: add iothread-vq-mapping parameter

Port over the iothread-vq-mapping qdev property from virtio-blk to virtio-scsi.

virtio-scsi: handle ctrl virtqueue in main loop

Simplify TMF handling now that there is no longer a single AioContext where all
requests are processed.

Stefan Hajnoczi (12):
  scsi-disk: drop unused SCSIDiskState->bh field
  dma: use current AioContext for dma_blk_io()
  scsi: track per-SCSIRequest AioContext
  scsi: introduce requests_lock
  virtio-scsi: introduce event and ctrl virtqueue locks
  virtio-scsi: protect events_dropped field
  virtio-scsi: perform TMFs in appropriate AioContexts
  virtio-blk: extract cleanup_iothread_vq_mapping() function
  virtio-blk: tidy up iothread_vq_mapping functions
  virtio: extract iothread-vq-mapping.h API
  virtio-scsi: add iothread-vq-mapping parameter
  virtio-scsi: handle ctrl virtqueue in main loop

 include/hw/scsi/scsi.h                  |   8 +-
 include/hw/virtio/iothread-vq-mapping.h |  45 ++
 include/hw/virtio/virtio-scsi.h         |  15 +-
 include/system/dma.h                    |   3 +-
 hw/block/virtio-blk.c                   | 132 +-----
 hw/ide/core.c                           |   3 +-
 hw/ide/macio.c                          |   3 +-
 hw/scsi/scsi-bus.c                      | 121 ++++--
 hw/scsi/scsi-disk.c                     |  24 +-
 hw/scsi/virtio-scsi-dataplane.c         |  96 +++--
 hw/scsi/virtio-scsi.c                   | 534 ++++++++++++++----------
 hw/virtio/iothread-vq-mapping.c         | 131 ++++++
 system/dma-helpers.c                    |   8 +-
 hw/virtio/meson.build                   |   1 +
 14 files changed, 672 insertions(+), 452 deletions(-)
 create mode 100644 include/hw/virtio/iothread-vq-mapping.h
 create mode 100644 hw/virtio/iothread-vq-mapping.c

Comments

Peter Krempa Feb. 20, 2025, 5:04 p.m. UTC | #1
On Thu, Feb 13, 2025 at 13:00:31 -0500, Stefan Hajnoczi wrote:
> Implement --device virtio-scsi-pci,iothread-vq-mapping= support so that
> virtqueues can be assigned to different IOThreads. This improves SMP guest
> scalability where I/O-intensive applications can become bottlenecked on a
> single IOThread.

Hi I was playing around with this along with the patches and I can see
that multiple iothreads do get loaded when I configure the mapping. It
was a bit tricky to spot it though among the 200-odd 'worker' threads
qemu spawned :D (but spawns also without this feature being used).

I didn't do any benchmarks ...

> The following benchmark results show the effect of iothread-vq-mapping. fio
> randread 4k iodepth=64 results from a 4 vCPU guest with an Intel P4800X SSD:
> iothreads IOPS
> ------------------------------
> 1         189576
> 2         312698
> 4         346744

... so I'll trust you here, but at least configuration wise this seems
to work.

As discussed on the libvirt patchset it might be a good idea to
docuement that the ctrl and event queues need to be mapped as well if
you'll be dealing with docs.

Tested-by: Peter Krempa <pkrempa@redhat.com>