From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCPo0-0002Wk-MQ for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:45:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCPnx-0002Qq-Ge for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:45:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51942) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCPnx-0002QQ-11 for qemu-devel@nongnu.org; Thu, 01 Dec 2016 06:45:33 -0500 Date: Thu, 1 Dec 2016 11:45:29 +0000 From: Stefan Hajnoczi Message-ID: <20161201114529.GA10441@stefanha-x1.localdomain> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <32e560b9-779a-3cd9-9320-2faf68e00107@scylladb.com> Subject: Re: [Qemu-devel] Linux kernel polling for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity 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 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > > > >=20 > > > > At the moment I'm still evaluating whether the good results we've g= otten > > > > from polling in QEMU userspace are preserved when polling is shifte= d to > > > > the kernel. > > > >=20 > > > > 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/133e8f1da8eb5364cd5c5f7162= decbc79175cd13 > > > This would add a system call every time the main loop processes a vri= ng, > > > wouldn't it? > > Yes, this is a problem and is the reason I haven't finished implementing > > a test using QEMU yet. > >=20 > > 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. > >=20 > > 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. > >=20 >=20 > Maybe we could do the same for sockets? When data is available on a sock= et > (or when it becomes writable), write to a user memory location. >=20 > 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? Stefan --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYQA1YAAoJEJykq7OBq3PIMQ8H/2rT8waVft41oaFNC2O0ZWuE SBrO8xv7ZiPyACQkT4rZZFPmzpmhnkWy8RW2SuuQv4RVDymAZTi4YP05IbBkYUyT PDWKYg5yVc+tPu9gqJckoPvHwQX3601H822iqe1TbbJ8EggOi2bo6vSxRDdO4V0n TZb+DA1scWZYPuu8xw84uu8+CWIO88sOTnXm0k+aixFALHnQ6C6TonQHpMfkt/qG HJKOfy1zFpoDL/mON3R3vsXMo0BGBMqa6wvXgZGYLEgjfrKWYq87SLcO1iBDkVQG n+Q37uMNF106h3G0e53hhKu/BLIZ5PRBCPkhdK2OYO+DQ8tJrBOkTTsGp1zu5+4= =BcDy -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE--