From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a97bg-00050P-W0 for qemu-devel@nongnu.org; Wed, 16 Dec 2015 03:38:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a97bc-0005y7-0Y for qemu-devel@nongnu.org; Wed, 16 Dec 2015 03:38:44 -0500 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:34628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a97bb-0005y3-Q8 for qemu-devel@nongnu.org; Wed, 16 Dec 2015 03:38:39 -0500 Received: by mail-wm0-x231.google.com with SMTP id l126so28809989wml.1 for ; Wed, 16 Dec 2015 00:38:39 -0800 (PST) Sender: Paolo Bonzini References: From: Paolo Bonzini Message-ID: <5671230C.70102@redhat.com> Date: Wed, 16 Dec 2015 09:38:36 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 0/3] virtio: proposal to optimize accesses to VQs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vincenzo Maffione , qemu-devel@nongnu.org Cc: g.lettieri@iet.unipi.it, jasowang@redhat.com, rizzo@iet.unipi.it, armbru@redhat.com, mst@redhat.com On 15/12/2015 23:33, Vincenzo Maffione wrote: > This patch slightly rewrites the code to reduce the number of accesses, since > many of them seems unnecessary to me. After this reduction, the bottleneck > jumps from 1 Mpps to 2 Mpps. Very nice. Did you get new numbers with the rebase? That would help measuring the effect of removing variable-sized memcpy (I'll post the patches for this shortly; they're entirely in memory.h/exec.c so they're not virtio-specific). A rough measurement from "perf" says they're worth about 5%. Related to this, patch 3 introduces a variable-sized memcpy, because it switches from 2 virtio_stl_phys to 1 address_space_write. I'm curious if the effect of this individual patch is positive, negative or neutral. On the other hand, patches 1 and 2 are clear wins. Paolo > Patch is not complete (e.g. it still does not properly manage endianess, it is > not clean, etc.). I just wanted to ask if you think the idea makes sense, and > a proper patch in this direction would be accepted.