Combining poll and epoll for optimal performance

[Marc Lehmann]

On Tue, Aug 03, 2010 at 01:32:50PM +0200, Hongli Lai <honglilai at gmail.com> wrote:
> According to the libev documentation, epoll has a higher overhead than
> select and poll. Zed Shaw recently confirmed these findings for epoll
> and poll. He states that poll tends to be faster than epoll as long as
> the active/total fd ratio is higher than 0.6.

That depends A LOT on the actual algorithm, which is likely to be very
different in libev than what zed tried (from what he describes it seems he
does a lot more syscalls than necessary).

> He's playing with this idea called 'superpoll' in which he combines
> poll and epoll: poll would be used when the active/total fd ratio is
> higher than 0.6, epoll otherwise.
> 
> Might this be an interesting thing to implement in libev as well?

Cannot be done without threads on linux, as epoll (despite documentation
claiming the contrary, tested up to 2.6.23) cannot be embedded (as kqueue
can for example), and poll is also not embeddable.

With threads, it's trivial, just run poll in one thread and epoll in
another.

If epoll ever gets fixed (unlikely), then all that needs to be done is to
remove the check in libev. With threads, libev works out of the box.

The latter is basically what zed does, except he starts another process
and uses zeromq, which to me sounds completely insane, as the extra
overhead surely cannot be compensated unless your epoll implementation is
really bad.

Of course, that could be done with libev just as well.

:)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\