From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7k2w-0004sH-Ce for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:21:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7k2q-0006cI-AJ for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:21:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52350) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7k2q-0006bv-1A for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:21:36 -0500 Date: Fri, 18 Nov 2016 16:21:33 +0200 From: "Michael S. Tsirkin" Message-ID: <20161118161309-mutt-send-email-mst@kernel.org> References: <1479333189-20082-1-git-send-email-stefanha@redhat.com> <20161117001658-mutt-send-email-mst@kernel.org> <20161117132749.GI24138@stefanha-x1.localdomain> <20161117193826-mutt-send-email-mst@kernel.org> <20161118105847.GE28853@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118105847.GE28853@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] [PATCH 0/3] virtio: disable notifications in blk and scsi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Stefan Hajnoczi , Kevin Wolf , zhunxun@gmail.com, Fam Zheng , qemu-devel@nongnu.org, Christian Borntraeger , Paolo Bonzini On Fri, Nov 18, 2016 at 10:58:47AM +0000, Stefan Hajnoczi wrote: > On Thu, Nov 17, 2016 at 07:38:45PM +0200, Michael S. Tsirkin wrote: > > On Thu, Nov 17, 2016 at 01:27:49PM +0000, Stefan Hajnoczi wrote: > > > On Thu, Nov 17, 2016 at 12:17:57AM +0200, Michael S. Tsirkin wrote: > > > > On Wed, Nov 16, 2016 at 09:53:06PM +0000, Stefan Hajnoczi wrote: > > > > > Disabling notifications during virtqueue processing reduces the number of > > > > > exits. The virtio-net device already uses virtio_queue_set_notifications() but > > > > > virtio-blk and virtio-scsi do not. > > > > > > > > > > The following benchmark shows a 15% reduction in virtio-blk-pci MMIO exits: > > > > > > > > > > (host)$ qemu-system-x86_64 \ > > > > > -enable-kvm -m 1024 -cpu host \ > > > > > -drive if=virtio,id=drive0,file=f24.img,format=raw,\ > > > > > cache=none,aio=native > > > > > (guest)$ fio # jobs=4, iodepth=8, direct=1, randread > > > > > (host)$ sudo perf record -a -e kvm:kvm_fast_mmio > > > > > > > > > > Number of kvm_fast_mmio events: > > > > > Unpatched: 685k > > > > > Patched: 592k (-15%, lower is better) > > > > > > > > Any chance to see a gain in actual benchmark numbers? > > > > This is important to make sure we are not just > > > > shifting overhead around. > > > > > > Good idea. I reran this morning without any tracing and compared > > > against bare metal. > > > > > > Total reads for a 30-second 4 KB random read benchmark with 4 processes > > > x iodepth=8: > > > > > > Bare metal: 26440 MB > > > Unpatched: 19799 MB > > > Patched: 21252 MB > > > > > > Patched vs Unpatched: +7% improvement > > > Patched vs Bare metal: 20% virtualization overhead > > > > > > The disk image is a 8 GB raw file on XFS on LVM on dm-crypt on a Samsung > > > MZNLN256HCHP 256 GB SATA SSD. This is just my laptop. > > > > > > Seems like a worthwhile improvement to me. > > > > > > Stefan > > > > Sure. Pls remember to ping or re-post after the release. > > How about a -next tree? -next would make sense if we did Linus style short merge cycles followed by a long stabilization period. With current QEMU style -next seems counter-productive, we do freezes in particular so people focus on stabilization, with -next everyone except maintainers just keeps going as usual, and maintainers must handle double the load. > I've found that useful for block, net, and tracing in the past. Most of > the time it means patch authors can rest assured their patches will be > merged without further action. It allows development of features that > depend on out-of-tree patches. > > Stefan Less work for authors, more work for me ... I'd rather distribute the load. -- MST