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 than > > qemu.git: > > > > syscall high # of fd low # of fd > > ------------------------------------------------- > > qemu.git(ppoll) 44 96 > > ppoll+epoll 85 101 > > timerfd+epoll 87 109 > > More data points. > > Xiaomei tested this series (applied on top of RHEL 7 qemu-kvm-rhev) and found > that: > > 0) when # of fds is high, epoll solutions are much better (+30%). > > 1) timerfd+epoll is slightly better than ppoll+epoll, but the difference is > minimal. > > 2) original code is 2%~5% faster than the new implementations when # of fds 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 optimizations. > Options in my mind are: > > 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". > > That said, I'll also look at the kernel side. Maybe optimizing ppoll or just > 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
pgp1Vxeu3Muh5.pgp
Description: PGP signature
