qemu-block
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

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