From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5agp-00083h-N3 for qemu-devel@nongnu.org; Tue, 02 May 2017 12:30:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5ago-0002Ha-8j for qemu-devel@nongnu.org; Tue, 02 May 2017 12:30:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47142) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5ago-0002Gr-34 for qemu-devel@nongnu.org; Tue, 02 May 2017 12:30:14 -0400 From: Markus Armbruster References: <1493732857-10721-1-git-send-email-den@openvz.org> <87bmrbgvzf.fsf@dusky.pond.sub.org> Date: Tue, 02 May 2017 18:30:08 +0200 In-Reply-To: (Denis V. Lunev's message of "Tue, 2 May 2017 18:29:39 +0300") Message-ID: <877f1zcjcf.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" "Denis V. Lunev" writes: > On 05/02/2017 05:43 PM, Markus Armbruster wrote: >> "Denis V. Lunev" 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 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 Signed-off-by: Anthony Liguori