From: Markus Armbruster <armbru@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>
Cc: qemu-devel@nongnu.org, "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, 02 May 2017 18:30:08 +0200 [thread overview]
Message-ID: <877f1zcjcf.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <e90d1680-6212-862e-bd3b-fdc415ec1890@openvz.org> (Denis V. Lunev's message of "Tue, 2 May 2017 18:29:39 +0300")
"Denis V. Lunev" <den@openvz.org> writes:
> On 05/02/2017 05:43 PM, Markus Armbruster wrote:
>> "Denis V. Lunev" <den@openvz.org> writes:
>>
>>> 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
>>> 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.
>> Can you explain briefly why this relies on "synchronous"? I've spent
>> all of two seconds on the question myself...
> Each command is processed in sequence as it appears in the
> channel. The answer to the command is sent and only after that
> next command is processed.
Yes, that's how QMP works.
> Theoretically tith asynchronous processing we can have some side
> effects due to changed buffer size.
What kind of side effects do you have in mind?
It's quite possible that this obviously inefficient way to read had some
deep reason back when it was created. Hmm, git-blame is our friend:
commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date: Fri Dec 4 14:05:29 2009 +0100
monitor: Accept input only byte-wise
This allows to suspend command interpretation and execution
synchronously, e.g. during migration.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
next prev parent reply other threads:[~2017-05-02 16:30 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
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 [this message]
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=877f1zcjcf.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=den@openvz.org \
--cc=dgilbert@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.