Exactly, nobody knows because they've been operating under the assumption that epoll is always faster so they never looked.
Now I've got some evicence that epoll isn't faster, and in fact it's a wash at 40% "utilization", which is sort of ridiculous. I'd want people to go and test and see what they get, or at least know the implications so they pick wisely.
Ultimately though, I'd rather have the Linux kernel just fix epoll so it's always faster than poll.
> Ultimately though, I'd rather have the Linux kernel just fix epoll so it's always faster than poll.
Unless they break poll, that's very unlikely. The implementation of poll is much simpler and should be faster per fd. What could happen is that epoll gets some improvement that moves up the .6 boundary but I seriously doubt epoll could ever be faster than poll with 100% active fds - and I never encountered that kind of usage.
As with any optimization, we should be concerned with end result: how much slower does using epoll really makes the system. I am on the skeptical side here.
Now I've got some evicence that epoll isn't faster, and in fact it's a wash at 40% "utilization", which is sort of ridiculous. I'd want people to go and test and see what they get, or at least know the implications so they pick wisely.
Ultimately though, I'd rather have the Linux kernel just fix epoll so it's always faster than poll.