From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCQ1t-0007T6-F3 for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:59:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCQ1p-0001dn-1Q for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:59:57 -0500 Received: from mail-wj0-x22a.google.com ([2a00:1450:400c:c01::22a]:35103) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCQ1o-0001cp-PY for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:59:52 -0500 Received: by mail-wj0-x22a.google.com with SMTP id v7so202314907wjy.2 for ; Thu, 01 Dec 2016 03:59:52 -0800 (PST) References: <20161124151225.GA11963@stefanha-x1.localdomain> <325f739a-05bd-c437-b9a2-e371a8cbf50d@linux.intel.com> <20161128152921.GA11196@stefanha-x1.localdomain> <73fa904a-7064-d692-6e8d-39161eaa8786@redhat.com> <20161129104505.GA1300@stefanha-x1.localdomain> <32e560b9-779a-3cd9-9320-2faf68e00107@scylladb.com> <20161201114529.GA10441@stefanha-x1.localdomain> From: Avi Kivity Message-ID: <9b1bf34e-e33b-777d-ef02-00b50b03440f@scylladb.com> Date: Thu, 1 Dec 2016 13:59:48 +0200 MIME-Version: 1.0 In-Reply-To: <20161201114529.GA10441@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Linux kernel polling for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Paolo Bonzini , Willem de Bruijn , Fam Zheng , Eliezer Tamir , Eric Dumazet , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Jens Axboe , Christian Borntraeger , Davide Libenzi , Christoph Hellwig On 12/01/2016 01:45 PM, Stefan Hajnoczi wrote: > On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote: >> On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote: >>> On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote: >>>> On 28/11/2016 16:29, Stefan Hajnoczi wrote: >>>>> Thanks for sharing the link. I'll let you know before embarking on an >>>>> effort to make epoll support busy_loop. >>>>> >>>>> At the moment I'm still evaluating whether the good results we've gotten >>>>> from polling in QEMU userspace are preserved when polling is shifted to >>>>> the kernel. >>>>> >>>>> FWIW I've prototyped ioctl(EVENTFD_SET_POLL_INFO) but haven't had a >>>>> chance to test it yet: >>>>> https://github.com/stefanha/linux/commit/133e8f1da8eb5364cd5c5f7162decbc79175cd13 >>>> This would add a system call every time the main loop processes a vring, >>>> wouldn't it? >>> Yes, this is a problem and is the reason I haven't finished implementing >>> a test using QEMU yet. >>> >>> My proposed eventfd polling mechanism doesn't work well with descriptor >>> ring indices because the polling info needs to be updated each event >>> loop iteration with the last seen ring index. >>> >>> This can be solved by making struct eventfd_poll_info.value take a >>> userspace memory address. The value to compare against is fetched each >>> polling iteration, avoiding the need for ioctl calls. >>> >> Maybe we could do the same for sockets? When data is available on a socket >> (or when it becomes writable), write to a user memory location. >> >> I, too, have an interest in polling; in my situation most of the polling >> happens in userspace. > You are trying to improve on the latency of non-blocking > ppoll(2)/epoll_wait(2) call? > Yes, but the concern is for throughput, not latency. My main loop looks like execute some tasks poll from many sources Since epoll_wait(..., 0) has non-trivial costs, I have to limit the polling rate, and even so it shows up in the profile. If the cost were lower, I could poll at a higher frequency, resulting in lower worst-case latencies for high-priority tasks.