You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Kegel <da...@alumni.caltech.edu> on 1999/05/14 16:44:08 UTC
/dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept
mutex)calls on hybrid server.)
Dean Gaudet wrote:
> (A person at Sun wrote:)
> > As of Solaris 7 a scheme refered to as /dev/poll was implemented such that
> > pollfd_t's are registered with the underlying FS (i.e. UFS, SOCKFS, ...)
> > and the FS does asynchronous notification. The end result is that poll()
> > now scales to tens of thousands of FDs per LWP (as well as a new API for
> > /dev/poll such that you open /dev/poll and do write()s (to register a number
> > of pollfd's) and read()s (to wait for, or in the case of nonblocking check
> > for, pollfd event(s)), using the /dev/poll API memory is your only limit
> > for scalability.
>
> Now that's real nice. I've been advocating this on linux kernel for a
> long time. Say hello to completion ports the unix way. I'm assuming they
> do the "right thing" and wake up in LIFO order, and allow you to read
> multiple events at once.
I have yet to use aio_ or F_SETSIG, but reading ready fd's from
/dev/poll
makes more sense to me than listening for realtime signals from aio_,
which according to http://www.deja.com/getdoc.xp?AN=366163395
can overflow, in which case the kernel sends a SIGIO to say 'realtime
signals overflowed, better do a full poll'. I'm contemplating writing
a server that uses aio_; that case kind of defeats the purpose of
using aio_, and handling it sounds annoying and suboptimal.
/dev/poll would never overflow in that way.
- Dan
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept
mutex)calls on hybrid server.)
Posted by Richard Gooch <rg...@atnf.csiro.au>.
Stephen C. Tweedie writes:
> Hi,
>
> On Sat, 29 May 1999 07:51:25 +1000, Richard Gooch <rg...@atnf.csiro.au> said:
>
> > Why not just increase the RT signal queue size? Add a command to
> > prctl(2) so the application can tune this.
>
> Letting the application increase the queue size opens up a DOS attack:
> you can lock down arbitrarily much non-swappable memory with it. root
> can already tune it via /proc/sys/kernel/rtsig-max.
OK, so there's a way for the administrator to tune this. I note the
default on my system is 1024, which should be fine for most
applications. However, for a busy WWW server, how deep should the
queue be? Anyone got a benchmark?
Assuming you need a much deeper queue (4096 for example), then tuning
rtsig-max will work, but at the cost of increasing the queue depth for
all processes, most of which won't need it. So how about creating
rtsig-limit and adding a command to prctl(2), so that a process which
needs to increase the queue depth can do so (up to the sysadmin tuned
limit), but other processes use the default?
Regards,
Richard....
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept
mutex)calls on hybrid server.)
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On Sat, 29 May 1999 07:51:25 +1000, Richard Gooch <rg...@atnf.csiro.au> said:
> Why not just increase the RT signal queue size? Add a command to
> prctl(2) so the application can tune this.
Letting the application increase the queue size opens up a DOS attack:
you can lock down arbitrarily much non-swappable memory with it. root
can already tune it via /proc/sys/kernel/rtsig-max.
--Stephen
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept
mutex)calls on hybrid server.)
Posted by Richard Gooch <rg...@atnf.csiro.au>.
Stephen C. Tweedie writes:
> Hi,
>
> On Fri, 14 May 1999 14:44:08 +0000, Dan Kegel <da...@alumni.caltech.edu>
> said:
>
> > I have yet to use aio_ or F_SETSIG, but reading ready fd's from
> > /dev/poll makes more sense to me than listening for realtime signals
> > from aio_, which according to
> > http://www.deja.com/getdoc.xp?AN=366163395 can overflow, in which case
> > the kernel sends a SIGIO to say 'realtime signals overflowed, better
> > do a full poll'.
>
> Yes.
>
> > I'm contemplating writing a server that uses aio_; that case kind of
> > defeats the purpose of using aio_, and handling it sounds annoying and
> > suboptimal.
>
> It adds code complexity but it shouldn't hurt the normal case: you don't
> expect to get an overflow unless you have a _lot_ of traffic coming
> through, in which case the cost of an occasional poll() to clear the
> queue shouldn't make much odds.
Why not just increase the RT signal queue size? Add a command to
prctl(2) so the application can tune this.
Regards,
Richard....
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept mutex)calls on hybrid server.)
Posted by Ulrich Drepper <dr...@cygnus.com>.
"Stephen C. Tweedie" <sc...@redhat.com> writes:
> Amen to that --- we _need_ CLONE_SIGNALS for this.
This is one of the things, yes. But it would be good to have a few
more things.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept mutex)calls on hybrid server.)
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On 28 May 1999 15:00:23 -0700, Ulrich Drepper <dr...@cygnus.com> said:
> "Stephen C. Tweedie" <sc...@redhat.com> writes:
>> However, it would be good to see real life profiling on this.
> Not without having a really good thread library first
Amen to that --- we _need_ CLONE_SIGNALS for this.
> or at least optimizing the aio library.
No, aio_* isn't used in this model: the reads and writes are
non-blocking already, it's just out-of-band activity indicators which we
need. aio_* is only useful for IO which is otherwise blocking.
--Stephen
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept mutex)calls on hybrid server.)
Posted by Ulrich Drepper <dr...@cygnus.com>.
"Stephen C. Tweedie" <sc...@redhat.com> writes:
> However, it would be good to see real life profiling on this.
Not without having a really good thread library first or at least
optimizing the aio library. The way I wrote it is *not* for optimized
performance, but instead for standard compliance. I will sometime
soon write an optimized version of the library and before this
happened it's kind of pointless to compare the methods for the purpose
of making long-term decisions.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
Re: /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept
mutex)calls on hybrid server.)
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On Fri, 14 May 1999 14:44:08 +0000, Dan Kegel <da...@alumni.caltech.edu>
said:
> I have yet to use aio_ or F_SETSIG, but reading ready fd's from
> /dev/poll makes more sense to me than listening for realtime signals
> from aio_, which according to
> http://www.deja.com/getdoc.xp?AN=366163395 can overflow, in which case
> the kernel sends a SIGIO to say 'realtime signals overflowed, better
> do a full poll'.
Yes.
> I'm contemplating writing a server that uses aio_; that case kind of
> defeats the purpose of using aio_, and handling it sounds annoying and
> suboptimal.
It adds code complexity but it shouldn't hurt the normal case: you don't
expect to get an overflow unless you have a _lot_ of traffic coming
through, in which case the cost of an occasional poll() to clear the
queue shouldn't make much odds.
However, it would be good to see real life profiling on this.
--Stephen