From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane
Date: Thu, 23 Jul 2015 19:43:36 +0800 [thread overview]
Message-ID: <20150723114336.GA12726@ad.nay.redhat.com> (raw)
In-Reply-To: <55B0A298.4020405@redhat.com>
On Thu, 07/23 10:15, Paolo Bonzini wrote:
>
>
> On 23/07/2015 08:32, Fam Zheng wrote:
> >
> > What is realized in this series is similar except the "disable, poll, enable"
> > method, instead the bit mask of interesting client types is passed to
> > aio_poll() (to be exact, passed to aio_poll_clients()). That is because,
> > aio_poll may release the AioContext lock around ppoll, avoiding state will make
> > the interface clearer.
>
> However, this means that you must keep the AioContext lock during all
> the long-running operations. Is this actually necessary? The original
> purpose of keeping the lock (which didn't quite work) was to block out
> dataplane operations.
I don't really see how we can avoid taking the lock around nested aio_poll
either way. Could you elaborate how it works in your original proposal?
>
> Also, this requirements means you really need the AioContext lock to be
> recursive. This is not a huge deal, but I'd prefer that requirement not
> to be too ingrained.
Regarding the AioContext lock, I see the point that it's an obstacle to
enabling virtio-scsi-dataplane MMIO.
Thinking out loud, maybe the recursive lock is too general: as you said, it has
always been used under BQL to block dataplane operations, instead of being
arbitrarily used by all kinds of threads. I'm wondering if we could just
replace it with some pause / resume mechanism of the dataplane iothreads (e.g.
iothread_pause / iothread_resume, a bit similar to block_job_pause)? That way,
aio_context_acquire can be dropped by:
/* @pause_owner_thread: a callback which will be called when _main thread_
* wants exclusively operate on the AioContext, for example with a nested
* aio_poll().
* @resume_owner_thread: a callback which will be called when _main thread_
* has done the exclusive operation.
*/
AioContext *aio_context_new(AioContextPauseResumeFn *pause_owner_thread,
AioContextPauseResumeFn *resume_owner_thread,
void *opaque,
Error **errp):
/* Try to pause the owning thread */
void aio_context_pause(AioContext *ctx, Error **errp);
/* Try to resume the paused owning thread, cannot fail */
void aio_context_resume(AioContext *ctx);
Then, in iothread.c:
iothread->ctx = aio_context_new(iothread_pause, iothread_resume,
iothread, &local_err);
Where iothread_pause can block the thread with a QemuCond.
Fam
next prev parent reply other threads:[~2015-07-23 11:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 6:32 [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 01/11] aio: Introduce "type" in aio_set_fd_handler and aio_set_event_notifier Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 02/11] aio: Save type to AioHandler Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 03/11] aio-posix: Introduce aio_poll_clients Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 04/11] aio-win32: Implement aio_poll_clients Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 05/11] block: Mark fd handlers as "protocol" Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 06/11] nbd: Mark fd handlers client type as "nbd server" Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 07/11] aio: Mark ctx->notifier's client type as "context" Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 08/11] dataplane: Mark host notifiers' client type as "dataplane" Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 09/11] block: Introduce bdrv_aio_poll Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 10/11] block: Replace nested aio_poll with bdrv_aio_poll Fam Zheng
2015-07-23 6:32 ` [Qemu-devel] [RFC PATCH 11/11] block: Only poll block layer fds in bdrv_aio_poll Fam Zheng
2015-07-23 8:15 ` [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane Paolo Bonzini
2015-07-23 11:43 ` Fam Zheng [this message]
2015-07-24 7:35 ` Paolo Bonzini
2015-07-27 6:55 ` Fam Zheng
2015-07-27 13:23 ` Paolo Bonzini
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=20150723114336.GA12726@ad.nay.redhat.com \
--to=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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).