From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8sDY-0007Gx-B4 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:08:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8sDU-0005dW-Be for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:08:16 -0500 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:47751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8sDU-0005dM-64 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 10:08:12 -0500 Received: by mail-wi0-f169.google.com with SMTP id r20so8259160wiv.0 for ; Wed, 07 Jan 2015 07:08:11 -0800 (PST) Date: Wed, 7 Jan 2015 15:08:08 +0000 From: Stefan Hajnoczi Message-ID: <20150107150808.GE22440@stefanha-thinkpad.redhat.com> References: <1417664590-23707-1-git-send-email-famz@redhat.com> <20141216020438.GA18251@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qFgkTsE6LiHkLPZw" Content-Disposition: inline In-Reply-To: <20141216020438.GA18251@ad.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/6] 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, Stefan Hajnoczi , xigao@redhat.com --qFgkTsE6LiHkLPZw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 10:04:38AM +0800, Fam Zheng wrote: > On Thu, 12/04 11:43, Fam Zheng wrote: > > v2: Emulate nanoseconds precison of timeout with ppoll and timerfd. > > Their performance is on par with each other, but both much better t= han > > qemu.git: > >=20 > > syscall high # of fd low # of fd > > ------------------------------------------------- > > qemu.git(ppoll) 44 96 > > ppoll+epoll 85 101 > > timerfd+epoll 87 109 >=20 > More data points. >=20 > Xiaomei tested this series (applied on top of RHEL 7 qemu-kvm-rhev) and f= ound > that: >=20 > 0) when # of fds is high, epoll solutions are much better (+30%). >=20 > 1) timerfd+epoll is slightly better than ppoll+epoll, but the difference = is > minimal. >=20 > 2) original code is 2%~5% faster than the new implementations when # of f= ds is > low. What is "high" and "low"? I'd like to understand whether they are extremes that almost no users will encounter or whether they are plausible in the real world. > This leads to the conclusion that that we'll have a small performance > degradation if merge this series. I'm thinking about possible optimizatio= ns. > Options in my mind are: >=20 > 1) Remove 1ns PR_SET_TIMERSLACK in timerfd+epoll, this doesn't make qemu_= poll > faster than the old qemu_poll_ns, but may have other positive effects that > compensate the cost. Sounds like a random hack. What is the reasoning for messing with timer slack? Perhaps it is worth investigating timer slack as an independent issue though. > 2) Use dynamic switch between ppoll and timerfd+epoll. In poll-linux.c, We > start with pure ppoll, while keeping track of elapsed time in ppoll. And > periodically, we try "timerfd+epoll" for a few iterations, so that we can > compare if it is faster than pure ppoll. If it is, swap them, use timerfd= +epoll > and and periodically try "ppoll". >=20 > That said, I'll also look at the kernel side. Maybe optimizing ppoll or j= ust > add EPOLL_NANOSECOND_TIMEOUT to epoll_create1 is a better place for > engineering. I agree that a kernel fix would be good. Even if the patch is rejected, we might get good ideas on how applications can optimize. Stefan --qFgkTsE6LiHkLPZw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrUvYAAoJEJykq7OBq3PItrcH/jW9u+3m6I/s1OkFsK0hB4lB c3P22MamFkbsfJ6zkW6qLhMbXpkKhBfHgN06iXz+LqsgsOq3czSn6ijNnftT2JQR JCiER2fIYUyalsJrUwELv5pZQOcKrLdgirBTK2F3Uphv7SAr5731pfhMILGzANDl nrFgPpol3ZzDrdIT3kedkqivAmOc3kzrLlyUsxVX4kq9F86GGIjFC1YSnALLW8Rh DsIhmtBrGrZqMK1tZy9NnEDTu0w9Hf0mfd0OGIy+XM7vSO3OYSMajJjPUW3Ucj+2 pERXQHAW0bLZ9Q2LXoW5jnTnBqTi6CfsMcMLP0FWcAXvzXPgkY+x1uElx68hwl4= =iEwo -----END PGP SIGNATURE----- --qFgkTsE6LiHkLPZw--