qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 7d5983: Introduce event-loop-base abstract cl


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 7d5983: Introduce event-loop-base abstract class
Date: Mon, 09 May 2022 12:41:25 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 7d5983e3c8c40b1d0668faba31d79905c4fadd7d
      
https://github.com/qemu/qemu/commit/7d5983e3c8c40b1d0668faba31d79905c4fadd7d
  Author: Nicolas Saenz Julienne <nsaenzju@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    A event-loop-base.c
    A include/sysemu/event-loop-base.h
    M include/sysemu/iothread.h
    M iothread.c
    M meson.build
    M qapi/qom.json

  Log Message:
  -----------
  Introduce event-loop-base abstract class

Introduce the 'event-loop-base' abstract class, it'll hold the
properties common to all event loops and provide the necessary hooks for
their creation and maintenance. Then have iothread inherit from it.

EventLoopBaseClass is defined as user creatable and provides a hook for
its children to attach themselves to the user creatable class 'complete'
function. It also provides an update_params() callback to propagate
property changes onto its children.

The new 'event-loop-base' class will live in the root directory. It is
built on its own using the 'link_whole' option (there are no direct
function dependencies between the class and its children, it all happens
trough 'constructor' magic). And also imposes new compilation
dependencies:

    qom <- event-loop-base <- blockdev (iothread.c)

And in subsequent patches:

    qom <- event-loop-base <- qemuutil (util/main-loop.c)

All this forced some amount of reordering in meson.build:

 - Moved qom build definition before qemuutil. Doing it the other way
   around (i.e. moving qemuutil after qom) isn't possible as a lot of
   core libraries that live in between the two depend on it.

 - Process the 'hw' subdir earlier, as it introduces files into the
   'qom' source set.

No functional changes intended.

Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20220425075723.20019-2-nsaenzju@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 70ac26b9e5ca8374bb3ef3f30b871726673c9f27
      
https://github.com/qemu/qemu/commit/70ac26b9e5ca8374bb3ef3f30b871726673c9f27
  Author: Nicolas Saenz Julienne <nsaenzju@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M event-loop-base.c
    M include/qemu/main-loop.h
    M include/sysemu/event-loop-base.h
    M meson.build
    M qapi/qom.json
    M util/main-loop.c

  Log Message:
  -----------
  util/main-loop: Introduce the main loop into QOM

'event-loop-base' provides basic property handling for all 'AioContext'
based event loops. So let's define a new 'MainLoopClass' that inherits
from it. This will permit tweaking the main loop's properties through
qapi as well as through the command line using the '-object' keyword[1].
Only one instance of 'MainLoopClass' might be created at any time.

'EventLoopBaseClass' learns a new callback, 'can_be_deleted()' so as to
mark 'MainLoop' as non-deletable.

[1] For example:
      -object main-loop,id=main-loop,aio-max-batch=<value>

Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20220425075723.20019-3-nsaenzju@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 71ad4713cc1d7fca24388b828ef31ae6cb38a31c
      
https://github.com/qemu/qemu/commit/71ad4713cc1d7fca24388b828ef31ae6cb38a31c
  Author: Nicolas Saenz Julienne <nsaenzju@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M event-loop-base.c
    M include/block/aio.h
    M include/block/thread-pool.h
    M include/sysemu/event-loop-base.h
    M iothread.c
    M qapi/qom.json
    M util/aio-posix.c
    M util/async.c
    M util/main-loop.c
    M util/thread-pool.c

  Log Message:
  -----------
  util/event-loop-base: Introduce options to set the thread pool size

The thread pool regulates itself: when idle, it kills threads until
empty, when in demand, it creates new threads until full. This behaviour
doesn't play well with latency sensitive workloads where the price of
creating a new thread is too high. For example, when paired with qemu's
'-mlock', or using safety features like SafeStack, creating a new thread
has been measured take multiple milliseconds.

In order to mitigate this let's introduce a new 'EventLoopBase'
property to set the thread pool size. The threads will be created during
the pool's initialization or upon updating the property's value, remain
available during its lifetime regardless of demand, and destroyed upon
freeing it. A properly characterized workload will then be able to
configure the pool to avoid any latency spikes.

Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20220425075723.20019-4-nsaenzju@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 2f743ef6366c2df4ef51ef3ae318138cdc0125ab
      
https://github.com/qemu/qemu/commit/2f743ef6366c2df4ef51ef3ae318138cdc0125ab
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi.c

  Log Message:
  -----------
  virtio-scsi: fix ctrl and event handler functions in dataplane mode

Commit f34e8d8b8d48d73f36a67b6d5e492ef9784b5012 ("virtio-scsi: prepare
virtio_scsi_handle_cmd for dataplane") prepared the virtio-scsi cmd
virtqueue handler function to be used in both the dataplane and
non-datpalane code paths.

It failed to convert the ctrl and event virtqueue handler functions,
which are not designed to be called from the dataplane code path but
will be since the ioeventfd is set up for those virtqueues when
dataplane starts.

Convert the ctrl and event virtqueue handler functions now so they
operate correctly when called from the dataplane code path. Avoid code
duplication by extracting this code into a helper function.

Fixes: f34e8d8b8d48d73f36a67b6d5e492ef9784b5012 ("virtio-scsi: prepare 
virtio_scsi_handle_cmd for dataplane")
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20220427143541.119567-2-stefanha@redhat.com
[Fixed s/by used/be used/ typo pointed out by Michael Tokarev
<mjt@tls.msk.ru>.
--Stefan]
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 38738f7dbbda90fbc161757b7f4be35b52205552
      
https://github.com/qemu/qemu/commit/38738f7dbbda90fbc161757b7f4be35b52205552
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi-dataplane.c
    M hw/virtio/virtio.c
    M include/hw/virtio/virtio.h

  Log Message:
  -----------
  virtio-scsi: don't waste CPU polling the event virtqueue

The virtio-scsi event virtqueue is not emptied by its handler function.
This is typical for rx virtqueues where the device uses buffers when
some event occurs (e.g. a packet is received, an error condition
happens, etc).

Polling non-empty virtqueues wastes CPU cycles. We are not waiting for
new buffers to become available, we are waiting for an event to occur,
so it's a misuse of CPU resources to poll for buffers.

Introduce the new virtio_queue_aio_attach_host_notifier_no_poll() API,
which is identical to virtio_queue_aio_attach_host_notifier() except
that it does not poll the virtqueue.

Before this patch the following command-line consumed 100% CPU in the
IOThread polling and calling virtio_scsi_handle_event():

  $ qemu-system-x86_64 -M accel=kvm -m 1G -cpu host \
      --object iothread,id=iothread0 \
      --device virtio-scsi-pci,iothread=iothread0 \
      --blockdev 
file,filename=test.img,aio=native,cache.direct=on,node-name=drive0 \
      --device scsi-hd,drive=drive0

After this patch CPU is no longer wasted.

Reported-by: Nir Soffer <nsoffer@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Nir Soffer <nsoffer@redhat.com>
Message-id: 20220427143541.119567-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 37ce2de95169dacab3fb53d11bd4509b9c2e3a4c
      
https://github.com/qemu/qemu/commit/37ce2de95169dacab3fb53d11bd4509b9c2e3a4c
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h

  Log Message:
  -----------
  virtio-scsi: clean up virtio_scsi_handle_event_vq()

virtio_scsi_handle_event_vq() is only called from hw/scsi/virtio-scsi.c
now and its return value is no longer used. Remove the function
prototype from virtio-scsi.h and drop the return value.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20220427143541.119567-4-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 73b3b49f1880f236b4d0ffd7efb00280c05a5fab
      
https://github.com/qemu/qemu/commit/73b3b49f1880f236b4d0ffd7efb00280c05a5fab
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h

  Log Message:
  -----------
  virtio-scsi: clean up virtio_scsi_handle_ctrl_vq()

virtio_scsi_handle_ctrl_vq() is only called from hw/scsi/virtio-scsi.c
now and its return value is no longer used. Remove the function
prototype from virtio-scsi.h and drop the return value.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20220427143541.119567-5-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: ad482b57ef841b2d4883c5079d20ba44ff5e4b3e
      
https://github.com/qemu/qemu/commit/ad482b57ef841b2d4883c5079d20ba44ff5e4b3e
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h

  Log Message:
  -----------
  virtio-scsi: clean up virtio_scsi_handle_cmd_vq()

virtio_scsi_handle_cmd_vq() is only called from hw/scsi/virtio-scsi.c
now and its return value is no longer used. Remove the function
prototype from virtio-scsi.h and drop the return value.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20220427143541.119567-6-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 3dc584abeef0e1277c2de8c1c1974cb49444eb0a
      
https://github.com/qemu/qemu/commit/3dc584abeef0e1277c2de8c1c1974cb49444eb0a
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h

  Log Message:
  -----------
  virtio-scsi: move request-related items from .h to .c

There is no longer a need to expose the request and related APIs in
virtio-scsi.h since there are no callers outside virtio-scsi.c.

Note the block comment in VirtIOSCSIReq has been adjusted to meet the
coding style.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20220427143541.119567-7-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>


  Commit: 178bacb66d98d9ee7a702b9f2a4dfcd88b72a9ab
      
https://github.com/qemu/qemu/commit/178bacb66d98d9ee7a702b9f2a4dfcd88b72a9ab
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2022-05-09 (Mon, 09 May 2022)

  Changed paths:
    A event-loop-base.c
    M hw/scsi/virtio-scsi-dataplane.c
    M hw/scsi/virtio-scsi.c
    M hw/virtio/virtio.c
    M include/block/aio.h
    M include/block/thread-pool.h
    M include/hw/virtio/virtio-scsi.h
    M include/hw/virtio/virtio.h
    M include/qemu/main-loop.h
    A include/sysemu/event-loop-base.h
    M include/sysemu/iothread.h
    M iothread.c
    M meson.build
    M qapi/qom.json
    M util/aio-posix.c
    M util/async.c
    M util/main-loop.c
    M util/thread-pool.c

  Log Message:
  -----------
  Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into 
staging

Pull request

- Add new thread-pool-min/thread-pool-max parameters to control the thread pool
  used for async I/O.

- Fix virtio-scsi IOThread 100% CPU consumption QEMU 7.0 regression.

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmJ5DqgACgkQnKSrs4Gr
# c8iAqAf/WEJzEso0Hu3UUYJi2lAXpLxWPjoNBlPdQlKIJ/I0zQIF0P7GeCifF+0l
# iMjgBv0ofyAuV47gaTJlVrAR75+hJ/IXNDhnu3UuvNWfVOqvksgw6kuHkMo9A2hC
# 4tIHEU9J8jbQSSdQTaZR8Zj4FX1/zcxMBAXT3YO3De6zo78RatBTuNP4dsZzt8bI
# Qs1a4A0p2ScNXK8EcF4QwAWfoxu9OPPzN52DBCNxcIcnn0SUab4NbDxzpRV4ZhDP
# 08WoafI5O+2Kb36QysJN01LqajHrClG/fozrPzBLq5aZUK3xewJGB1hEdGTLkkmz
# NJNBg5Ldszwj4PDZ1dFU3/03aigb3g==
# =t5eR
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 09 May 2022 05:52:56 AM PDT
# gpg:                using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]

* tag 'block-pull-request' of https://gitlab.com/stefanha/qemu:
  virtio-scsi: move request-related items from .h to .c
  virtio-scsi: clean up virtio_scsi_handle_cmd_vq()
  virtio-scsi: clean up virtio_scsi_handle_ctrl_vq()
  virtio-scsi: clean up virtio_scsi_handle_event_vq()
  virtio-scsi: don't waste CPU polling the event virtqueue
  virtio-scsi: fix ctrl and event handler functions in dataplane mode
  util/event-loop-base: Introduce options to set the thread pool size
  util/main-loop: Introduce the main loop into QOM
  Introduce event-loop-base abstract class

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/b0c3c60366ed...178bacb66d98



reply via email to

[Prev in Thread] Current Thread [Next in Thread]