From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0lPs-0006ec-0A for qemu-devel@nongnu.org; Wed, 19 Apr 2017 04:56:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0lPq-0000XM-OA for qemu-devel@nongnu.org; Wed, 19 Apr 2017 04:56:48 -0400 Received: from mail-qk0-x232.google.com ([2607:f8b0:400d:c09::232]:35859) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0lPq-0000Wm-Hf for qemu-devel@nongnu.org; Wed, 19 Apr 2017 04:56:46 -0400 Received: by mail-qk0-x232.google.com with SMTP id d131so14416744qkc.3 for ; Wed, 19 Apr 2017 01:56:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Jiahuan Zhang Date: Wed, 19 Apr 2017 10:56:45 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] Hight Processor time of Socket communciation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 18 April 2017 at 18:26, Peter Maydell wrote: > On 18 April 2017 at 17:19, Jiahuan Zhang wrote: > > Dear QEMU developers, > > I am measuring the processor time for guest-host communication via > socket. > > The guest app is to write a 5M image to a serial device. > > The serial deivce is redirected to the socket in the command line. > > The host app is to receive the data via socket until the peer closes the > > connection. > > Please find in the attachment the Processor time graph generated by > Windows > > Performance Monitor. > > > > The graph shows the processor time is almost 100% while communicating. > > Surprising me! My expectation is 1%. > > > > I wonder if this is the right performance for QEMU socket communciation? > Or > > this high processor time is caused by the serial device? If so, any > > optimization I can do? > > The serial device on the vexpress-a9 model is a PL011, which > is a fairly simple UART which all data must be written to > byte-at-a-time. This is never going to be fast, because we > have to execute a lot of guest code to send the data through > this byte-at-a-time bottleneck, and since you're running > a purely emulated QEMU, executing guest code means doing > a lot of CPU operations. > Hi Peter, Do you mean that it is reasonable for QEMU emulation consumes high CPU time when doing host-guest interaction, since the interaction calls many QEMU codes in the background? The situation i met is that, 1. after socket connection is done and i enter the guest kernel console, QEMU's processor time is very low although some some callback functiona are polling. 2. when i start the guest app to send data to the serial device, which is redirected to the socket, the processor time becomes very high. 3. when the data transfer is done, the processor time recovers to be low again. Since my guest app is rather simple and no while() is included, according to your words, can I conclude that the high processor time is cause by the callbacks for guest to host data transfer? > You will likely get better throughput if you use the 'virt' board > where you can use the virtio-serial device which can send > data more efficiently. > Here, can I understand your statement in this way, a transmit buffer in the serial device for guest to host data transfer may reduce the processor time, and in turn, increase the throughput? Because the transmit buffer can enable multi-byte data to be transfered. Then, taking the char-socket as an example, less tcp_char_write will be called when the "len" varible is larger than 1. Please rectify me if my logic is wrong. Thanks. Regards, huan > thanks > -- PMM >