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 are 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 optimization is patch 4.
v5->v6:
* Rebased to tag: v5.0.0-rc3 (SHA-1 20038cd7).
* Dropped patch 2 ("9pfs readdir: rename max_count -> maxsize").
Message-ID of previous version (v5):
cover.1585258105.git.qemu_...@crudebyte.com
Message-ID of version with performance benchmark (v4):
cover.1579567019.git.qemu_...@crudebyte.com
Christian Schoenebeck (5):
tests/virtio-9p: added split readdir tests
9pfs: make v9fs_readdir_response_size() public
9pfs: add new function v9fs_co_readdir_many()
9pfs: T_readdir latency optimization
9pfs: clarify latency of v9fs_co_run_in_worker()
hw/9pfs/9p.c | 130 ++++++++++++-------------
hw/9pfs/9p.h | 23 +++++
hw/9pfs/codir.c | 181 ++++++++++++++++++++++++++++++++---
hw/9pfs/coth.h | 15 ++-
tests/qtest/virtio-9p-test.c | 108 +++++++++++++++++++++
5 files changed, 377 insertions(+), 80 deletions(-)
--
2.20.1
