From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6IjU-0003hM-Nf for qemu-devel@nongnu.org; Mon, 14 Nov 2016 09:59:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6IjS-00005J-4o for qemu-devel@nongnu.org; Mon, 14 Nov 2016 09:59:40 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37417 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6IjR-00005D-UM for qemu-devel@nongnu.org; Mon, 14 Nov 2016 09:59:38 -0500 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAEEx0Ub084075 for ; Mon, 14 Nov 2016 09:59:37 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 26qdd3xgr7-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Nov 2016 09:59:36 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Nov 2016 14:59:35 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id E42042190056 for ; Mon, 14 Nov 2016 14:58:46 +0000 (GMT) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uAEExXp928573712 for ; Mon, 14 Nov 2016 14:59:33 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uAEExXJj000641 for ; Mon, 14 Nov 2016 07:59:33 -0700 References: <1478711602-12620-1-git-send-email-stefanha@redhat.com> From: Christian Borntraeger Date: Mon, 14 Nov 2016 15:59:32 +0100 MIME-Version: 1.0 In-Reply-To: <1478711602-12620-1-git-send-email-stefanha@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Message-Id: Subject: Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , qemu-devel@nongnu.org Cc: Paolo Bonzini , Fam Zheng , Karl Rister On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote: > Recent performance investigation work done by Karl Rister shows that the > guest->host notification takes around 20 us. This is more than the "overhead" > of QEMU itself (e.g. block layer). > > One way to avoid the costly exit is to use polling instead of notification. > The main drawback of polling is that it consumes CPU resources. In order to > benefit performance the host must have extra CPU cycles available on physical > CPUs that aren't used by the guest. > > This is an experimental AioContext polling implementation. It adds a polling > callback into the event loop. Polling functions are implemented for virtio-blk > virtqueue guest->host kick and Linux AIO completion. > > The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to > poll before entering the usual blocking poll(2) syscall. Try setting this > variable to the time from old request completion to new virtqueue kick. > > By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any > polling! > > Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS > values. If you don't find a good value we should double-check the tracing data > to see if this experimental code can be improved. > > Stefan Hajnoczi (3): > aio-posix: add aio_set_poll_handler() > virtio: poll virtqueues for new buffers > linux-aio: poll ring for completions > > aio-posix.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > block/linux-aio.c | 17 +++++++ > hw/virtio/virtio.c | 19 ++++++++ > include/block/aio.h | 16 +++++++ > 4 files changed, 185 insertions(+) > Another observation: With more iothreads than host CPUs the performance drops significantly.