epoll more scalable than poll
Quoted 8 lines · Martin Waitz
Quoted 3 lines · Hanna Linder
The results of our testing show not only does the system call
interface to epoll perform as well as the /dev interface but also that epoll is many times better than standard poll. No other implementations of poll have performed as well as epoll in any measure. Testing details and results are published here, please take a minute to check it out:
http://lse.sourceforge.net/epoll/index.htmlhow does this compare to the kqueue mechanism found in {Free,Net}BSD? (see http://people.freebsd.org/~jlemon/papers/kqueue.pdf)
Quoted 7 lines
i especially like their combined event update/event wait, needing only one syscall per poll while building a changelist in userspace...
a replacement for poll/select is _really_ needed. but i think we should use existing interfaces if possible, to reduce the changes needed in userspace.
I'd kinda like to see a unified event queue object used uniformly for everything. You might instantiate several of them in one process (so e.g. libraries could have their own).
The idea of using the kqueue interface was discussed once before. See
http://marc.theaimsgroup.com/?l=linux-kernel&m=97236943118139&w=2
for Linus' opinion of kqueues (he doesn't like them much).
Another existing event queue for readiness notification to be delivered via is Ben's AIO completion notification queue, but I haven't heard a definitive story about whether epoll events could be delivered that way. (The discussion seems to always veer into a discussion of asynchronous poll, which is something else.)
- Dan
Quoted 3 lines · Dan Kegel
The idea of using the kqueue interface was discussed once before. See
http://marc.theaimsgroup.com/?l=linux-kernel&m=97236943118139&w=2
for Linus' opinion of kqueues (he doesn't like them much).
Hang on - reading again, I wonder if the main reason he didn't like kqueue is because it allowed for multiple event queues (so libraries don't need to be tightly integrated into the main program, for instance). He preferred one queue and callbacks.
However, I think Linus admitted later on that nobody liked his callback idea, so maybe he'd be receptive to the multiple event queue idea now.
Um, I assume Ben's aio stuff allows multiple completion queues, right?
- Dan
Quoted 6 lines · Dan Kegel
Another existing event queue for readiness notification to be delivered via is Ben's AIO completion notification queue, but I haven't heard a definitive story about whether epoll events could be delivered that way. (The discussion seems to always veer into a discussion of asynchronous poll, which is something else.)
Yep Dan, Ben proposed that approach that we did not have the time to test. The way of returning events of sys_epoll is very efficent, like you can see in the scalability page ( pipetest ) that Hanna and her team setup :
http://lse.sourceforge.net/epoll/index.html
- Davide
Quoted 8 lines · Davide Libenzi
Quoted 6 lines · Dan Kegel
Another existing event queue for readiness notification to be delivered via is Ben's AIO completion notification queue, but I haven't heard a definitive story about whether epoll events could be delivered that way. (The discussion seems to always veer into a discussion of asynchronous poll, which is something else.)
Quoted 5 lines
Yep Dan, Ben proposed that approach that we did not have the time to test. The way of returning events of
sys_epollis very efficent, like you can see in the scalability page ( pipetest ) that Hanna and her team setup :
I do like those results. If, however, the unified approach performs as well, it might be good to go with it to reduce the number of interfaces, as Martin suggested. (Though he was suggesting kqueue as the preferred interface, not Ben's aio...)
- Dan