From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7hTT-0005nq-I8 for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:36:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7hTO-0005gu-Gw for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:36:55 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34441) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7hTO-0005gp-7k for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:36:50 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAIBXZBx117179 for ; Fri, 18 Nov 2016 06:36:48 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 26sw2eb7ct-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2016 06:36:48 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 Nov 2016 11:36:46 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4629017D805D for ; Fri, 18 Nov 2016 11:39:09 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uAIBah5m28049474 for ; Fri, 18 Nov 2016 11:36:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uAIBahF1029763 for ; Fri, 18 Nov 2016 04:36:43 -0700 References: <1479333189-20082-1-git-send-email-stefanha@redhat.com> <20161118110256.GF28853@stefanha-x1.localdomain> From: Christian Borntraeger Date: Fri, 18 Nov 2016 12:36:43 +0100 MIME-Version: 1.0 In-Reply-To: <20161118110256.GF28853@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Message-Id: 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 , qemu-devel@nongnu.org, Kevin Wolf , Paolo Bonzini , zhunxun@gmail.com, Fam Zheng , "Michael S. Tsirkin" On 11/18/2016 12:02 PM, Stefan Hajnoczi wrote: > On Thu, Nov 17, 2016 at 12:01:30PM +0100, Christian Borntraeger wrote: >> On 11/16/2016 10:53 PM, 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) >>> >>> Note that a workload with iodepth=1 and a single thread will not benefit - this >>> is a batching optimization. The effect should be strongest with large iodepth >>> and multiple threads submitting I/O. The guest I/O scheduler also affects the >>> optimization. >> >> I have trouble seeing any difference in terms of performances or CPU load (other than >> a reduced number of kicks). >> I was expecting some benefit by reducing the spinlock hold times in virtio-blk, >> but this needs some more setups to actually find the sweet spot. > > Are you testing on s390 with ccw? Yes I'm not familiar with the performance > characteristics of the kick under ccw. The kick is a diagnose instruction, that exits the guest into the host kernel. In the host kernel it will notify an eventfd and return back to the guest, so in essence it should be the same as x86. I was using host ramdisks, maybe this has affected the performance. > >> Maybe it will show its benefit with the polling thing? > > Yes, I hope it will benefit polling. I'll build patches for polling on > top of this. >