apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: [PATCH] sys_epoll Support for apr_pollset
Date Fri, 04 Jun 2004 23:59:14 GMT
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

Mime
View raw message