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 <s...@redhat.com> > --- > 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
