From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Denis V. Lunev" <den@openvz.org>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read
Date: Tue, 2 May 2017 15:44:26 +0100 [thread overview]
Message-ID: <20170502144426.GE16624@redhat.com> (raw)
In-Reply-To: <da1ab237-5dd0-cae9-7eb9-687203b37a64@redhat.com>
On Tue, May 02, 2017 at 09:34:55AM -0500, Eric Blake wrote:
> On 05/02/2017 08:47 AM, Denis V. Lunev wrote:
> > Right now QMP and HMP monitors read 1 byte at a time from the socket, which
> > is very inefficient. With 100+ VMs on the host this easily reasults in
>
> s/reasults/results/
>
> > a lot of unnecessary system calls and CPU usage in the system.
> >
> > This patch changes the amount of data to read to 4096 bytes, which matches
> > buffer size on the channel level. Fortunately, monitor protocol is
> > synchronous right now thus we should not face side effects in reality.
>
> Do you have any easy benchmarks or measurements to prove what sort of
> efficiencies we get? (I believe they exist, but quantifying them never
> hurts)
>
> >
> > Signed-off-by: Denis V. Lunev <den@openvz.org>
> > CC: Markus Armbruster <armbru@redhat.com>
> > CC: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > CC: Eric Blake <eblake@redhat.com>
> > ---
> > monitor.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index be282ec..00df5d0 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -3698,7 +3698,7 @@ static int monitor_can_read(void *opaque)
> > {
> > Monitor *mon = opaque;
> >
> > - return (mon->suspend_cnt == 0) ? 1 : 0;
> > + return (mon->suspend_cnt == 0) ? 4096 : 0;
>
> Is a hard-coded number correct, or should we be asking the channel for
> an actual number?
There's no need - this will cause the chardev code to just do a
gio_channel_read() with a 4096 byte buffer. The chardev backend
impl will then happily return fewer bytes than this - just whatever
happens to be pending. IOW this is just acting as an upper bound
on the amount of data we read at once. So 4k seems reasonable to
me, given the typical size of QMP/HMP command strings.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2017-05-02 14:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 13:47 [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read Denis V. Lunev
2017-05-02 14:34 ` Eric Blake
2017-05-02 14:44 ` Daniel P. Berrange [this message]
2017-05-02 14:49 ` Dr. David Alan Gilbert
2017-05-02 14:55 ` Daniel P. Berrange
2017-05-02 15:37 ` Denis V. Lunev
2017-05-02 14:43 ` Markus Armbruster
2017-05-02 15:29 ` Denis V. Lunev
2017-05-02 16:30 ` Markus Armbruster
2017-05-02 16:36 ` Dr. David Alan Gilbert
2017-05-02 16:48 ` Daniel P. Berrange
2017-05-02 17:00 ` Dr. David Alan Gilbert
2017-05-02 17:07 ` Denis V. Lunev
2017-05-03 11:29 ` Markus Armbruster
2017-05-03 11:34 ` Denis V. Lunev
2017-05-10 15:54 ` Markus Armbruster
2017-05-10 16:01 ` Denis V. Lunev
2017-05-03 11:35 ` Daniel P. Berrange
2017-05-03 11:39 ` Denis V. Lunev
2017-05-03 11:55 ` Marc-André Lureau
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=20170502144426.GE16624@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--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).