[PATCH v2 0/9] 9pfs: readdir optimization

Christian Schoenebeck posted 9 patches 4 years, 4 months ago
Test asan failed
Test checkpatch failed
Test FreeBSD failed
Test docker-mingw@fedora failed
Test docker-clang@ubuntu failed
Test docker-quick@centos7 failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/cover.1576678644.git.qemu_oss@crudebyte.com
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, Laurent Vivier <lvivier@redhat.com>, Greg Kurz <groug@kaod.org>, Thomas Huth <thuth@redhat.com>
There is a newer version of this series
hw/9pfs/9p-synth.c     |  48 ++++++++++-
hw/9pfs/9p-synth.h     |   5 ++
hw/9pfs/9p.c           | 151 ++++++++++++++++++---------------
hw/9pfs/9p.h           |  23 +++++
hw/9pfs/codir.c        | 183 +++++++++++++++++++++++++++++++++++++---
hw/9pfs/coth.h         |   3 +
tests/virtio-9p-test.c | 186 ++++++++++++++++++++++++++++++++++++++++-
7 files changed, 516 insertions(+), 83 deletions(-)
[PATCH v2 0/9] 9pfs: readdir optimization
Posted by Christian Schoenebeck 4 years, 4 months ago
As previously mentioned, I was investigating performance issues with 9pfs.
Raw file read/write of 9pfs is actually quite good, provided that client
picked a reasonable high msize (maximum message size). I would recommend
to log a warning on 9p server side if a client attached with a small msize
that would cause performance issues for that reason.

However there other aspects where 9pfs currently performs suboptimally,
especially readdir handling of 9pfs is extremely slow, a simple readdir
request of a guest typically blocks for several hundred milliseconds or
even several seconds, no matter how powerful the underlying hardware is.
The reason for this performance issue: latency.
Currently 9pfs is heavily dispatching a T_readdir request numerous times
between main I/O thread and a background I/O thread back and forth; in fact
it is actually hopping between threads even multiple times for every single
directory entry during T_readdir request handling which leads in total to
huge latencies for a single T_readdir request.

This patch series aims to address this severe performance issue of 9pfs
T_readdir request handling. The actual performance fix is patch 8. I also
provided a convenient benchmark for comparing the performance improvements
by using the 9pfs "synth" driver (see patch 6 for instructions how to run
the benchmark), so no guest OS installation is required to peform this
benchmark A/B comparison. With patch 8 I achieved a performance improvement
of factor 40 on my test machine.

** NOTE: ** These patches are not heavily tested yet, nor thouroughly
reviewed for potential security issues yet. I decided to post them already
though, because I won't have the time in the next few weeks for polishing
them. The benchmark results should demonstrate though that it is worth the
hassle. So any testing/reviews/fixes appreciated!

v1->v2:

  * Fixed missing email threading of this patch set.

  * Fixed code style issues.

  * No need to check for NULL when calling g_free() [patch 4] and
    [patch 8].

  * No need to initialize static variable with NULL [patch 7].

  * Adjustments to commit log messages.

Christian Schoenebeck (9):
  tests/virtio-9p: add terminating null in v9fs_string_read()
  9pfs: validate count sent by client with T_readdir
  hw/9pfs/9p-synth: added directory for readdir test
  tests/virtio-9p: added readdir test
  tests/virtio-9p: check file names of R_readdir response
  9pfs: readdir benchmark
  hw/9pfs/9p-synth: avoid n-square issue in synth_readdir()
  9pfs: T_readdir latency optimization
  hw/9pfs/9p.c: benchmark time on T_readdir request

 hw/9pfs/9p-synth.c     |  48 ++++++++++-
 hw/9pfs/9p-synth.h     |   5 ++
 hw/9pfs/9p.c           | 151 ++++++++++++++++++---------------
 hw/9pfs/9p.h           |  23 +++++
 hw/9pfs/codir.c        | 183 +++++++++++++++++++++++++++++++++++++---
 hw/9pfs/coth.h         |   3 +
 tests/virtio-9p-test.c | 186 ++++++++++++++++++++++++++++++++++++++++-
 7 files changed, 516 insertions(+), 83 deletions(-)

-- 
2.20.1