From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtGY4-00012v-M8 for qemu-devel@nongnu.org; Tue, 25 Nov 2014 08:53:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtGXu-0001Vd-Lo for qemu-devel@nongnu.org; Tue, 25 Nov 2014 08:52:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtGXu-0001VV-Ei for qemu-devel@nongnu.org; Tue, 25 Nov 2014 08:52:46 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAPDqiPv011182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 25 Nov 2014 08:52:45 -0500 Date: Tue, 25 Nov 2014 13:52:43 +0000 From: Stefan Hajnoczi Message-ID: <20141125135243.GJ21126@stefanha-thinkpad.redhat.com> References: <1416902879-17422-1-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NgG1H2o5aFKkgPy/" Content-Disposition: inline In-Reply-To: <1416902879-17422-1-git-send-email-famz@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing qemu_poll abstraction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org --NgG1H2o5aFKkgPy/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 25, 2014 at 04:07:54PM +0800, Fam Zheng wrote: > ppoll(2) doesn't scale as well as epoll: The elapsed time of the syscall = is > linear to the number of fd's we poll, which hurts performance a bit when = the > number of devices are many, or when a virtio device registers many virtqu= eues > (virtio-serial, for instance). >=20 > To show some data from my test on current master: >=20 > - As a base point (10~20 fd's), it takes 22000 ns for each qemu_poll_ns. > - Add 10 virtio-serial, which adds some 6 hundreds of fd's in the main l= oop. > The time spent in qemu_poll_ns goes up to 75000 ns. >=20 > This series introduces qemu_poll, which is implemented with g_poll and e= poll, > decided at configure time with CONFIG_EPOLL. >=20 > After this change, the times to do the same thing with qemu_poll (more > precisely, with a sequence of qemu_poll_set_fds(), qemu_poll(), > qemu_poll_get_events() followed by syncing back to gpollfds), are reduced= to > 21000 ns and 25000 ns, respectively. >=20 > We are still not O(1) because as a transition, the qemu_poll_set_fds befo= re > qemu_poll is not optimized out yet. You didn't mention the change from nanosecond to millisecond timeouts. QEMU did not use g_poll() for a long time because g_poll() only provides milliseconds. It seems this patch series undoes the work that has been done to keep nanosecond timeouts in QEMU. Do you think it is okay to forget about <1 ms timeout precision? If we go ahead with this, we'll need to rethink other timeouts in QEMU. For example, is there a point in setting timer slack to 1 ns if we cannot even specify ns wait times? Perhaps timerfd is needed before we can use epoll. Hopefully the overall performance effect will be positive with epoll + timerfd, compared to ppoll(). Stefan --NgG1H2o5aFKkgPy/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUdImrAAoJEJykq7OBq3PILrEH/iNYr6lvx8UiyRHZ1W1GvWSG /62CVrNZw5IQ9h3e7p+YGWZze5ekZIVtW69tRcKnwQ0G8xK24ySWk2/yTjKAzjgi quEzRLlmT28DmU9go6wEq0xZnZea2AZoQDkUEP91SWYVouQqnf6AOMbZKQs52f/I O7Dmge4cHMQRvYvoH+03k6MuphthkhuzehIcb3VvC92Fu3JKFcEbsauwXq+ysEZP olFMTKtDqIuxu3GOiGC2+eDHM24l1HgaBU9LS1naCsCrF92yra2uTMwEy8znPZaL J8sWC8R7IUgGbNg0ucujueIiKx/zpWoQR9AzQHs9AJXmqMFP7JFzpzPGmLmVVv8= =NJeu -----END PGP SIGNATURE----- --NgG1H2o5aFKkgPy/--