From: Greg Kurz <groug@kaod.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Fam Zheng <fam@euphon.net>, Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC 0/8] virtio: Improve boot time of virtio-scsi-pci and virtio-blk-pci
Date: Thu, 25 Mar 2021 19:05:34 +0100 [thread overview]
Message-ID: <20210325190534.7fbdb942@bahia.lan> (raw)
In-Reply-To: <20210325130429-mutt-send-email-mst@kernel.org>
On Thu, 25 Mar 2021 13:05:16 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Mar 25, 2021 at 04:07:27PM +0100, Greg Kurz wrote:
> > Now that virtio-scsi-pci and virtio-blk-pci map 1 virtqueue per vCPU,
> > a serious slow down may be observed on setups with a big enough number
> > of vCPUs.
> >
> > Exemple with a pseries guest on a bi-POWER9 socket system (128 HW threads):
> >
> > 1 0m20.922s 0m21.346s
> > 2 0m21.230s 0m20.350s
> > 4 0m21.761s 0m20.997s
> > 8 0m22.770s 0m20.051s
> > 16 0m22.038s 0m19.994s
> > 32 0m22.928s 0m20.803s
> > 64 0m26.583s 0m22.953s
> > 128 0m41.273s 0m32.333s
> > 256 2m4.727s 1m16.924s
> > 384 6m5.563s 3m26.186s
> >
> > Both perf and gprof indicate that QEMU is hogging CPUs when setting up
> > the ioeventfds:
> >
> > 67.88% swapper [kernel.kallsyms] [k] power_pmu_enable
> > 9.47% qemu-kvm [kernel.kallsyms] [k] smp_call_function_single
> > 8.64% qemu-kvm [kernel.kallsyms] [k] power_pmu_enable
> > =>2.79% qemu-kvm qemu-kvm [.] memory_region_ioeventfd_before
> > =>2.12% qemu-kvm qemu-kvm [.] address_space_update_ioeventfds
> > 0.56% kworker/8:0-mm [kernel.kallsyms] [k] smp_call_function_single
> >
> > address_space_update_ioeventfds() is called when committing an MR
> > transaction, i.e. for each ioeventfd with the current code base,
> > and it internally loops on all ioventfds:
> >
> > static void address_space_update_ioeventfds(AddressSpace *as)
> > {
> > [...]
> > FOR_EACH_FLAT_RANGE(fr, view) {
> > for (i = 0; i < fr->mr->ioeventfd_nb; ++i) {
> >
> > This means that the setup of ioeventfds for these devices has
> > quadratic time complexity.
> >
> > This series introduce generic APIs to allow batch creation and deletion
> > of ioeventfds, and converts virtio-blk and virtio-scsi to use them. This
> > greatly improves the numbers:
> >
> > 1 0m21.271s 0m22.076s
> > 2 0m20.912s 0m19.716s
> > 4 0m20.508s 0m19.310s
> > 8 0m21.374s 0m20.273s
> > 16 0m21.559s 0m21.374s
> > 32 0m22.532s 0m21.271s
> > 64 0m26.550s 0m22.007s
> > 128 0m29.115s 0m27.446s
> > 256 0m44.752s 0m41.004s
> > 384 1m2.884s 0m58.023s
> >
> > The series deliberately spans over multiple subsystems for easier
> > review and experimenting. It also does some preliminary fixes on
> > the way. It is thus posted as an RFC for now, but if the general
> > idea is acceptable, I guess a non-RFC could be posted and maybe
> > extend the feature to some other devices that might suffer from
> > similar scaling issues, e.g. vhost-scsi-pci, vhost-user-scsi-pci
> > and vhost-user-blk-pci, even if I haven't checked.
> >
> > This should fix https://bugzilla.redhat.com/show_bug.cgi?id=1927108
> > which reported the issue for virtio-scsi-pci.
>
>
> Series looks ok from a quick look ...
>
> this is a regression isn't it?
This is a regression only if we consider the defaults. Manually setting
num_queues to a high value already affects existing devices.
> So I guess we'll need that in 6.0 or revert the # of vqs
> change for now ...
>
Not sure it is safe to merge these fixes this late... also,
as said above, I've only tested virtio-scsi and virtio-blk
but I believe the vhost-user-* variants might be affected too.
Reverting the # of vqs would really be a pity IMHO. What
about mitigating the effects ? e.g. enforce previous
behavior only if # vcpus > 64 ?
> > Greg Kurz (8):
> > memory: Allow eventfd add/del without starting a transaction
> > virtio: Introduce virtio_bus_set_host_notifiers()
> > virtio: Add API to batch set host notifiers
> > virtio-pci: Batch add/del ioeventfds in a single MR transaction
> > virtio-blk: Fix rollback path in virtio_blk_data_plane_start()
> > virtio-blk: Use virtio_bus_set_host_notifiers()
> > virtio-scsi: Set host notifiers and callbacks separately
> > virtio-scsi: Use virtio_bus_set_host_notifiers()
> >
> > hw/virtio/virtio-pci.h | 1 +
> > include/exec/memory.h | 48 ++++++++++++++++------
> > include/hw/virtio/virtio-bus.h | 7 ++++
> > hw/block/dataplane/virtio-blk.c | 26 +++++-------
> > hw/scsi/virtio-scsi-dataplane.c | 68 ++++++++++++++++++--------------
> > hw/virtio/virtio-bus.c | 70 +++++++++++++++++++++++++++++++++
> > hw/virtio/virtio-pci.c | 53 +++++++++++++++++--------
> > softmmu/memory.c | 42 ++++++++++++--------
> > 8 files changed, 225 insertions(+), 90 deletions(-)
> >
> > --
> > 2.26.3
> >
>
next prev parent reply other threads:[~2021-03-25 18:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 15:07 [RFC 0/8] virtio: Improve boot time of virtio-scsi-pci and virtio-blk-pci Greg Kurz
2021-03-25 15:07 ` [RFC 1/8] memory: Allow eventfd add/del without starting a transaction Greg Kurz
2021-03-29 17:03 ` Stefan Hajnoczi
2021-03-30 7:47 ` Greg Kurz
2021-03-30 10:16 ` Stefan Hajnoczi
2021-03-25 15:07 ` [RFC 2/8] virtio: Introduce virtio_bus_set_host_notifiers() Greg Kurz
2021-03-29 17:06 ` Stefan Hajnoczi
2021-03-25 15:07 ` [RFC 3/8] virtio: Add API to batch set host notifiers Greg Kurz
2021-03-29 17:10 ` Stefan Hajnoczi
2021-03-30 10:17 ` Greg Kurz
2021-03-30 13:55 ` Stefan Hajnoczi
2021-03-30 14:17 ` Greg Kurz
2021-03-31 14:47 ` Stefan Hajnoczi
2021-03-31 16:21 ` Greg Kurz
2021-03-25 15:07 ` [RFC 4/8] virtio-pci: Batch add/del ioeventfds in a single MR transaction Greg Kurz
2021-03-29 17:24 ` Stefan Hajnoczi
2021-03-30 10:29 ` Greg Kurz
2021-03-25 15:07 ` [RFC 5/8] virtio-blk: Fix rollback path in virtio_blk_data_plane_start() Greg Kurz
2021-03-29 17:25 ` Stefan Hajnoczi
2021-03-25 15:07 ` [RFC 6/8] virtio-blk: Use virtio_bus_set_host_notifiers() Greg Kurz
2021-03-29 17:26 ` Stefan Hajnoczi
2021-03-25 15:07 ` [RFC 7/8] virtio-scsi: Set host notifiers and callbacks separately Greg Kurz
2021-03-25 15:07 ` [RFC 8/8] virtio-scsi: Use virtio_bus_set_host_notifiers() Greg Kurz
2021-03-29 17:28 ` Stefan Hajnoczi
2021-03-25 17:05 ` [RFC 0/8] virtio: Improve boot time of virtio-scsi-pci and virtio-blk-pci Michael S. Tsirkin
2021-03-25 17:43 ` Stefan Hajnoczi
2021-03-25 20:51 ` Greg Kurz
2021-03-25 18:05 ` Greg Kurz [this message]
2021-03-29 17:35 ` Stefan Hajnoczi
2021-03-30 13:15 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210325190534.7fbdb942@bahia.lan \
--to=groug@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=fam@euphon.net \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.