From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>,
Christian Schoenebeck <qemu_oss@crudebyte.com>
Subject: Re: 9p: requests efficiency
Date: Thu, 21 Nov 2019 00:37:36 +0100 [thread overview]
Message-ID: <2782774.O0duVuAc2B@silver> (raw)
In-Reply-To: <20191115142656.4f2c0f4b@bahia.lan>
On Freitag, 15. November 2019 14:26:56 CET Greg Kurz wrote:
> > However when there are a large number of (i.e. small) 9p requests, no
> > matter what the actual request type is, then I am encountering severe
> > performance issues with 9pfs and I try to understand whether this could
> > be improved with reasonable effort.
>
> Thanks for doing that. This is typically the kind of effort I never
> dared starting on my own.
If you don't mind I still ask some more questions though, just in case you can
gather them from the back of your head.
> > If I understand it correctly, each incoming request (T message) is
> > dispatched to its own qemu coroutine queue. So individual requests should
> > already be processed in parallel, right?
>
> Sort of but not exactly. The real parallelization, ie. doing parallel
> processing with concurrent threads, doesn't take place on a per-request
> basis.
Ok I see, I was just reading that each request causes this call sequence:
handle_9p_output() -> pdu_submit() -> qemu_co_queue_init(&pdu->complete)
and I was misinterpreting specifically that latter call to be an implied
thread creation. Because that's what happens with other somewhat similar
collaborative thread synchronization frameworks like "Grand Central Dispatch"
or std::async.
But now I realize the entire QEMU coroutine framework is really just managing
memory stacks, not actually anything about threads per se. The QEMU docs often
use the term "threads" which is IMO misleading for what it really does.
> A typical request is broken down into several calls to the backend
> which may block because the backend itself calls a syscall that may block
> in the kernel. Each backend call is thus handled by its own thread from the
> mainloop thread pool (see hw/9pfs/coth.[ch] for details). The rest of the
> 9p code, basically everything in 9p.c, is serialized in the mainloop thread.
So the precise parallelism fork points in 9pfs (where tasks are dispatched to
other threads) are the *_co_*() functions, and there precisely at where they
are using v9fs_co_run_in_worker( X ) respectively, correct? Or are there more
fork points than those?
If so, I haven't understood how precisely v9fs_co_run_in_worker() works. I
mean I understand now how QEMU coroutines are working, and the idea of
v9fs_co_run_in_worker() is dispatching the passed code block to the worker
thread, but immediately returning back to main thread and continueing there on
main thread with other coroutines while the worker thread's dispatched
coroutine finished. But how that happens there precisely in
v9fs_co_run_in_worker() is not yet clear to me.
Also where are the worker threads spawned actually?
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2019-11-20 23:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 1:10 9p: requests efficiency Christian Schoenebeck
2019-11-15 13:26 ` Greg Kurz
2019-11-20 23:37 ` Christian Schoenebeck [this message]
2019-11-23 19:26 ` Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2782774.O0duVuAc2B@silver \
--to=qemu_oss@crudebyte.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).