9pfs: clarify latency of v9fs_co_run_in_worker()

As we just fixed a severe performance issue with Treaddir request
handling, clarify this overall issue as a comment on
v9fs_co_run_in_worker() with the intention to hopefully prevent
such performance mistakes in future (and fixing other yet
outstanding ones).

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <4d34d332e1aaa8a2cf8dc0b5da4fd7727f2a86e8.1596012787.git.qemu_oss@crudebyte.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
This commit is contained in:
Christian Schoenebeck 2020-07-29 10:42:28 +02:00
parent d2c5cf7ca1
commit da9f2eda25

View File

@ -19,7 +19,7 @@
#include "qemu/coroutine.h"
#include "9p.h"
/*
/**
* we want to use bottom half because we want to make sure the below
* sequence of events.
*
@ -28,6 +28,16 @@
* 3. Enter the coroutine in the worker thread.
* we cannot swap step 1 and 2, because that would imply worker thread
* can enter coroutine while step1 is still running
*
* @b PERFORMANCE @b CONSIDERATIONS: As a rule of thumb, keep in mind
* that hopping between threads adds @b latency! So when handling a
* 9pfs request, avoid calling v9fs_co_run_in_worker() too often, because
* this might otherwise sum up to a significant, huge overall latency for
* providing the response for just a single request. For that reason it
* is highly recommended to fetch all data from fs driver with a single
* fs driver request on a background I/O thread (bottom half) in one rush
* first and then eventually assembling the final response from that data
* on main I/O thread (top half).
*/
#define v9fs_co_run_in_worker(code_block) \
do { \