[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC PATCH] aio: Add a knob to always poll if there are
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [RFC PATCH] aio: Add a knob to always poll if there are in-flight requests |
Date: |
Tue, 9 Apr 2019 12:26:08 +0100 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
On Tue, Apr 02, 2019 at 02:19:08PM +0200, Sergio Lopez wrote:
> The polling mode in aio_poll is able to trim down ~20us on the average
> request latency, but it needs manual fine tuning to adjust it to the
> characteristics of the storage.
>
> Here we add a new knob to the IOThread object, "poll-inflight". When
> this knob is enabled, aio_poll will always use polling if there are
> in-flight requests, ignoring the rest of poll-* parameters. If there
> aren't any in-flight requests, the usual polling rules apply, which is
> useful given that the default poll-max-ns value of 32us is usually
> enough to catch a new request in the VQ when the Guest is putting
> pressure on us.
>
> To keep track of the number of in-flight requests, AioContext has a
> new counter which is increased/decreased by thread-pool.c and
> linux-aio.c on request submission/completion.
>
> With poll-inflight, users willing to spend more Host CPU resources in
> exchange for a lower latency just need to enable a single knob.
>
> This is just an initial version of this feature and I'm just sharing
> it to get some early feedback. As such, managing this property through
> QAPI is not yet implemented.
>
> Signed-off-by: Sergio Lopez <address@hidden>
> ---
> block/linux-aio.c | 7 +++++++
> include/block/aio.h | 9 ++++++++-
> include/sysemu/iothread.h | 1 +
> iothread.c | 33 +++++++++++++++++++++++++++++++++
> util/aio-posix.c | 32 +++++++++++++++++++++++++++++++-
> util/thread-pool.c | 3 +++
> 6 files changed, 83 insertions(+), 2 deletions(-)
Hi Sergio,
More polling modes are useful for benchmarking and performance analysis.
From this perspective I think poll-inflight is worthwhile.
Like most performance optimizations, the effectiveness of this new
polling mode depends on the workload. It could waste CPU, especially on
a queue depth 1 workload with a slow disk.
Do you think better self-tuning is possible? Then users don't need to
set tunables like this one.
Stefan
signature.asc
Description: PGP signature