On Sun, May 30, 2004 at 02:52:08PM -0700, Paul Querna wrote: > On Sun, 2004-05-30 at 13:26 +0100, Joe Orton wrote: > > Interesting... some nits: > > > > - C++ // comments bad ;) > > - CPP #directives must not have leading whitespace before the # > > Fixed in the updated patch.
Good stuff... > > - needs to cope with the fact that glibc implements epoll* returning > > ENOSYS or whatever on 2.4 kernels IIRC, via autoconf or runtime checks > > I would prefer doing this in autoconf, unless people are willing to > accept a much larger patch that could make the pollset back end > selectable at runtime. The other issue with this is if APR was built on > a machine running 2.6, it might not be usable on a machine with 2.4. > That would be the other advantage of making the pollset back end runtime > selectable. Yeah, this kind of thing is a little annoying, but autoconf checks are really the only way, indeed. I guess by the time there's a stable httpd release based on APR 1.0, the 2.6 kernel will be old hat anyway :) > I did a simple benchmark with an epoll enabled HTTPd 2.1 yesterday. > [mostly to see if it all worked correctly :) ] > > It did a few transactions a second _faster_ than a normal poll() based > HTTPd 2.1. Not significantly better or worse for Apache's common case > of not very many sockets. Cool. > Maybe later this week I can make up some more official benchmarks. > > > I wondered whether apr_poll() should remain using poll() with it's low > > constant overhead, and the apr_pollset_* interface alone should use the > > high-constant-overhead interfaces like epoll or /dev/poll? > > Maybe. I don't think poll's overhead is much less than epoll. We will > have to benchmark it to find a real answer. Well, epoll is about scaling better; it means you can set up a descriptor array with two thousand fds, and not have to copy that array between kernel and userspace each time you call epoll_wait(), as you would with poll(). That's the slow bit (AIUI anyway). But for apr_poll(), that doesn't make any difference; you're setting up a new fd array for each call into APR anyway. So it may as well use poll(); in fact, it is probably *worse* to use epoll for apr_poll(), because it just has more overhead (with more system calls), and no advantages. Does that make sense? joe
