aboutsummaryrefslogtreecommitdiff
path: root/hw/9pfs/9p.h
diff options
context:
space:
mode:
authorChristian Schoenebeck <qemu_oss@crudebyte.com>2020-07-29 10:13:05 +0200
committerChristian Schoenebeck <qemu_oss@crudebyte.com>2020-08-12 09:17:32 +0200
commit0c4356ba7dafc8ecb5877a42fc0d68d45ccf5951 (patch)
treeb0438d3aa8d13d4a86eb66456fcc06d1fc0301b2 /hw/9pfs/9p.h
parent2149675b195f2d9a1a4e3b966d45aba234def69b (diff)
9pfs: T_readdir latency optimization
Make top half really top half and bottom half really bottom half: Each T_readdir request handling is hopping between threads (main I/O thread and background I/O driver threads) several times for every individual directory entry, which sums up to huge latencies for handling just a single T_readdir request. Instead of doing that, collect now all required directory entries (including all potentially required stat buffers for each entry) in one rush on a background I/O thread from fs driver by calling the previously added function v9fs_co_readdir_many() instead of v9fs_co_readdir(), then assemble the entire resulting network response message for the readdir request on main I/O thread. The fs driver is still aborting the directory entry retrieval loop (on the background I/O thread inside of v9fs_co_readdir_many()) as soon as it would exceed the client's requested maximum R_readdir response size. So this will not introduce a performance penalty on another end. Also: No longer seek initial directory position in v9fs_readdir(), as this is now handled (more consistently) by v9fs_co_readdir_many() instead. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <c7c3d1cf4e86611538cef44897842819d9359d7a.1596012787.git.qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Diffstat (limited to 'hw/9pfs/9p.h')
0 files changed, 0 insertions, 0 deletions