From: Peter Xu <peterx@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <shajnocz@redhat.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
mdroth@linux.vnet.ibm.com, Eric Blake <eblake@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
marcandre.lureau@redhat.com,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [RFC v5 16/26] monitor: separate QMP parser and dispatcher
Date: Sat, 16 Dec 2017 14:37:03 +0800 [thread overview]
Message-ID: <20171216063703.GD22308@xz-mi> (raw)
In-Reply-To: <20171213200938.GG8317@stefanha-x1.localdomain>
On Wed, Dec 13, 2017 at 08:09:38PM +0000, Stefan Hajnoczi wrote:
> On Tue, Dec 05, 2017 at 01:51:50PM +0800, Peter Xu wrote:
> > @@ -3956,12 +3968,122 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens,
> > }
> > }
> >
> > -err_out:
> > - monitor_qmp_respond(mon, rsp, err, id);
> > + /* Respond if necessary */
> > + monitor_qmp_respond(mon, rsp, NULL, id);
> > +
> > + /* This pairs with the monitor_suspend() in handle_qmp_command(). */
> > + if (!qmp_oob_enabled(mon)) {
> > + monitor_resume(mon);
>
> monitor_resume() does not work between threads: if the event loop is
> currently blocked in poll() it won't notice that the monitor fd should
> be watched again.
>
> Please add aio_notify() to monitor_resume() and monitor_suspend(). That
> way the event loop is forced to check can_read() again.
Ah, yes. I think monitor_suspend() does not need the notify? Since
if it's sleeping it won't miss the next check in can_read() after all?
Regarding to monitor_resume(), I noticed that I missed the fact that
it's only tailored for HMP before, which seems to be a bigger problem.
Do you agree with a change like this?
diff --git a/monitor.c b/monitor.c
index 9970418d6f..8f96880ad7 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4244,10 +4244,12 @@ int monitor_suspend(Monitor *mon)
void monitor_resume(Monitor *mon)
{
- if (!mon->rs)
- return;
if (atomic_dec_fetch(&mon->suspend_cnt) == 0) {
- readline_show_prompt(mon->rs);
+ if (monitor_is_qmp(mon)) {
+ aio_notify(mon_global.mon_iothread->ctx);
+ } else {
+ assert(mon->rs);
+ readline_show_prompt(mon->rs);
+ }
}
}
Even, I'm thinking about whether I should start to introduce
iothread_notify() now to mask out the IOThread.ctx details.
>
> > + }
> >
> > qobject_decref(req);
> > }
> >
> > +/*
> > + * Pop one QMP request from monitor queues, return NULL if not found.
> > + * We are using round-robin fasion to pop the request, to avoid
> > + * processing command only on a very busy monitor. To achieve that,
> > + * when we processed one request on specific monitor, we put that
> > + * monitor to the end of mon_list queue.
> > + */
> > +static QMPRequest *monitor_qmp_requests_pop_one(void)
> > +{
> > + QMPRequest *req_obj = NULL;
> > + Monitor *mon;
> > +
> > + qemu_mutex_lock(&monitor_lock);
> > +
> > + QTAILQ_FOREACH(mon, &mon_list, entry) {
> > + qemu_mutex_lock(&mon->qmp.qmp_queue_lock);
>
> Please add a doc comment about the monitor_lock < qmp_queue_lock lock
> ordering in the qmp_queue_lock field declaration so that deadlocks can
> be prevented.
Will do.
>
> > + req_obj = g_queue_pop_head(mon->qmp.qmp_requests);
> > + qemu_mutex_unlock(&mon->qmp.qmp_queue_lock);
> > + if (req_obj) {
> > + break;
> > + }
> > + }
> > +
> > + if (req_obj) {
> > + /*
> > + * We found one request on the monitor. Degrade this monitor's
> > + * priority to lowest by re-inserting it to end of queue.
> > + */
> > + QTAILQ_REMOVE(&mon_list, mon, entry);
> > + QTAILQ_INSERT_TAIL(&mon_list, mon, entry);
> > + }
> > +
> > + qemu_mutex_unlock(&monitor_lock);
> > +
> > + return req_obj;
> > +}
> > +
> > +static void monitor_qmp_bh_dispatcher(void *data)
> > +{
> > + QMPRequest *req_obj;
> > +
> > + while (true) {
>
> Previously QEMU could only dispatch 1 QMP command per main loop
> iteration. Now multiple requests can be processed in a single main loop
> iteration.
>
> If a producer enqueues requests faster than the dispatcher can dequeue
> them then this is infinite loop will prevent the caller (i.e. QEMU main
> loop) from making progress.
>
> The following keeps 1 QMP command per main loop iteration and avoids the
> infinite loop:
>
> static void monitor_qmp_bh_dispatcher(void *data)
> {
> QMPRequest *req_obj = monitor_qmp_requests_pop_one();
>
> if (req_obj) {
> monitor_qmp_dispatch_one(req_obj);
>
> /* Reschedule instead of looping so the main loop stays responsive */
> qemu_bh_schedule(mon_global.qmp_dispatcher_bh);
> }
> }
Yes, this sounds better!
>
> > + /*
> > + * Put the request to the end of queue so that requests will be
> > + * handled in time order. Ownership for req_obj, req, id,
> > + * etc. will be delivered to the handler side.
> > + */
> > + qemu_mutex_lock(&mon->qmp.qmp_queue_lock);
> > + g_queue_push_tail(mon->qmp.qmp_requests, req_obj);
> > + qemu_mutex_unlock(&mon->qmp.qmp_queue_lock);
> > +
> > + /* Kick the dispatcher routine */
> > + qemu_bh_schedule(mon_global.qmp_dispatcher_bh);
> > +
> > + /*
> > + * If OOB is not enabled on current monitor, we'll emulate the old
> > + * behavior that we won't process current monitor any more until
> > + * it is responded. This helps make sure that as long as OOB is
> > + * not enabled, the server will never drop any command.
> > + */
> > + if (!qmp_oob_enabled(mon)) {
> > + monitor_suspend(mon);
> > + }
>
> monitor_suspend() must be called before g_queue_push_tail(). Otherwise
> the other thread might complete the request and call monitor_resume()
> before we call monitor_suspend().
Reasonable. Thanks,
--
Peter Xu
next prev parent reply other threads:[~2017-12-16 6:37 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 5:51 [Qemu-devel] [RFC v5 00/26] QMP: out-of-band (OOB) execution support Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 01/26] qobject: introduce qstring_get_try_str() Peter Xu
2017-12-13 15:25 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 02/26] qobject: introduce qobject_get_try_str() Peter Xu
2017-12-13 15:25 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 03/26] qobject: let object_property_get_str() use new API Peter Xu
2017-12-13 15:27 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 04/26] monitor: move skip_flush into monitor_data_init Peter Xu
2017-12-13 15:28 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 05/26] qjson: add "opaque" field to JSONMessageParser Peter Xu
2017-12-13 15:37 ` Stefan Hajnoczi
2017-12-15 7:55 ` Peter Xu
2017-12-15 12:45 ` Stefan Hajnoczi
2017-12-16 3:28 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 06/26] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-12-13 15:41 ` Stefan Hajnoczi
2017-12-15 8:02 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 07/26] monitor: unify global init Peter Xu
2017-12-13 15:48 ` Stefan Hajnoczi
2017-12-15 8:11 ` Peter Xu
2017-12-15 12:47 ` Stefan Hajnoczi
2017-12-16 3:52 ` Peter Xu
2017-12-16 9:01 ` Stefan Hajnoczi
2017-12-18 3:27 ` Peter Xu
2017-12-18 9:24 ` Stefan Hajnoczi
2017-12-18 10:10 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 08/26] monitor: let mon_list be tail queue Peter Xu
2017-12-13 15:49 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 09/26] monitor: create monitor dedicate iothread Peter Xu
2017-12-13 16:20 ` Stefan Hajnoczi
2017-12-15 8:31 ` Peter Xu
2017-12-15 13:21 ` Stefan Hajnoczi
2017-12-16 4:42 ` Peter Xu
2017-12-16 4:50 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 10/26] monitor: allow to use IO thread for parsing Peter Xu
2017-12-13 16:35 ` Stefan Hajnoczi
2017-12-15 8:50 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 11/26] qmp: introduce QMPCapability Peter Xu
2017-12-13 16:56 ` Stefan Hajnoczi
2017-12-15 9:14 ` Peter Xu
2017-12-15 9:38 ` Fam Zheng
2017-12-16 3:58 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 12/26] qmp: negociate QMP capabilities Peter Xu
2017-12-12 17:39 ` Dr. David Alan Gilbert
2017-12-13 17:19 ` Stefan Hajnoczi
2017-12-15 9:40 ` Fam Zheng
2017-12-15 13:26 ` Stefan Hajnoczi
2017-12-15 13:53 ` Fam Zheng
2017-12-16 5:34 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 13/26] qmp: introduce some capability helpers Peter Xu
2017-12-12 17:44 ` Dr. David Alan Gilbert
2017-12-13 17:20 ` Stefan Hajnoczi
2017-12-15 9:42 ` Fam Zheng
2017-12-16 5:45 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 14/26] monitor: introduce monitor_qmp_respond() Peter Xu
2017-12-13 17:35 ` Stefan Hajnoczi
2017-12-16 5:52 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 15/26] monitor: let suspend_cnt be thread safe Peter Xu
2017-12-13 18:43 ` Stefan Hajnoczi
2017-12-16 6:12 ` Peter Xu
2017-12-16 9:11 ` Stefan Hajnoczi
2017-12-18 5:16 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 16/26] monitor: separate QMP parser and dispatcher Peter Xu
2017-12-13 20:09 ` Stefan Hajnoczi
2017-12-16 6:37 ` Peter Xu [this message]
2017-12-16 6:46 ` Peter Xu
2017-12-16 9:23 ` Stefan Hajnoczi
2017-12-18 5:26 ` Peter Xu
2017-12-18 9:10 ` Stefan Hajnoczi
2017-12-18 10:03 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 17/26] qmp: add new event "request-dropped" Peter Xu
2017-12-14 11:16 ` Stefan Hajnoczi
2017-12-16 6:59 ` Peter Xu
2017-12-14 11:32 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 18/26] monitor: send event when request queue full Peter Xu
2017-12-14 11:41 ` Stefan Hajnoczi
2017-12-16 7:17 ` Peter Xu
2017-12-16 9:28 ` Stefan Hajnoczi
2017-12-18 5:32 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 19/26] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-12-14 12:42 ` Stefan Hajnoczi
2017-12-15 9:51 ` Fam Zheng
2017-12-16 7:34 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 20/26] qmp: support out-of-band (oob) execution Peter Xu
2017-12-14 13:16 ` Stefan Hajnoczi
2017-12-18 5:37 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 21/26] qmp: isolate responses into io thread Peter Xu
2017-12-14 13:43 ` Stefan Hajnoczi
2017-12-18 5:52 ` Peter Xu
2017-12-18 7:32 ` Peter Xu
2017-12-18 8:40 ` Stefan Hajnoczi
2017-12-18 10:15 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 22/26] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-12-14 13:44 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 23/26] qmp: add command "x-oob-test" Peter Xu
2017-12-14 13:45 ` Stefan Hajnoczi
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 24/26] docs: update QMP documents for OOB commands Peter Xu
2017-12-14 14:30 ` Stefan Hajnoczi
2017-12-18 9:44 ` Peter Xu
2017-12-18 14:09 ` Stefan Hajnoczi
2017-12-19 3:18 ` Peter Xu
2017-12-05 5:51 ` [Qemu-devel] [RFC v5 25/26] tests: qmp-test: verify command batching Peter Xu
2017-12-14 14:39 ` Stefan Hajnoczi
2017-12-18 9:48 ` Peter Xu
2017-12-05 5:52 ` [Qemu-devel] [RFC v5 26/26] tests: qmp-test: add oob test Peter Xu
2017-12-14 14:47 ` Stefan Hajnoczi
2017-12-18 9:51 ` Peter Xu
2017-12-18 13:59 ` Stefan Hajnoczi
2017-12-14 14:52 ` [Qemu-devel] [RFC v5 00/26] QMP: out-of-band (OOB) execution support Stefan Hajnoczi
2017-12-19 6:05 ` Peter Xu
2017-12-15 10:41 ` Fam Zheng
2017-12-15 11:43 ` Dr. David Alan Gilbert
2017-12-15 13:30 ` Stefan Hajnoczi
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=20171216063703.GD22308@xz-mi \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=shajnocz@redhat.com \
--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).