From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5an0-0003WV-0Q for qemu-devel@nongnu.org; Tue, 02 May 2017 12:36:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5amx-0008Db-Lk for qemu-devel@nongnu.org; Tue, 02 May 2017 12:36:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18136) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5amx-0008C8-F4 for qemu-devel@nongnu.org; Tue, 02 May 2017 12:36:35 -0400 Date: Tue, 2 May 2017 17:36:30 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20170502163629.GA5640@work-vm> References: <1493732857-10721-1-git-send-email-den@openvz.org> <87bmrbgvzf.fsf@dusky.pond.sub.org> <877f1zcjcf.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877f1zcjcf.fsf@dusky.pond.sub.org> 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: Markus Armbruster Cc: "Denis V. Lunev" , qemu-devel@nongnu.org * Markus Armbruster (armbru@redhat.com) wrote: > "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 I don't think I understand why that's a problem; if we read more bytes, we're not going to interpret them and execute them until after the previous command returns are we? Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK