Why? Apache 1.2 (in particular) uses select() on a single fd to determine
if a read would block. Before you complain that this is silly and Apache
should use non-blocking i/o, I'd like to point out that Apache runs on
many architectures and we can't always assume things work. Besides, the
need for this one non-blocking check is related to supporting pipelining
http/1.1 clients in a network-efficient manner.
BTW, Linux needs poll(). Apache's select() fd_sets are always sparse in
the configs that people usually use. I intend to get apache post-1.2
using poll() on those architectures that have it, I expect to see a
decrease in sys-time.
Dean
On 21 May 1997, Michael O'Reilly wrote:
> smurf@work.smurf.noris.de (Matthias Urlichs) writes:
>
> > Andi Kleen <andi@mind.aec.at> writes:
> > > Oskar Pearson <oskar@is.co.za> writes:
> > >
> > > > This is with 2.0.30 with the filehandle patch from
> > > > www.linux.org.za/filehandle.patch.linux (or
> > > > ftp://ftp.is.co.za/linux/local/filehandle.patch.linux)
> > > >
> > > You can't run a unpatched 2.0 kernel with 3000fds per process.
> > > The sys_select() routine will overflow the kernel stack: it puts
> >
> > Ahem. He did mention the above patch. This patch tries to fix sys/select so
> > that the stack overrun will not happen.
> >
> > Unfortunately, that particular patch does seem to cause trouble. I've had
> > more success with my own change to fs/select.c, appended below.
>
> [ ... ]
>
> > + seldata = kmalloc(6*selsize,GFP_KERNEL);
> > + error = -ENOMEM;
> > + if(seldata == NULL)
>
> You REALLY want to cache the results of the kmalloc().
>
> Things that need a large select such as squid, and ircd, tend to call
> select() a LOT. (squid is frequently over 150 times a second). Caching
> the results of the kmalloc tends to give you a big win there.
>
> The use of an int to handle small value of select wasn't much of a win
> on the machines that I was playing with, but admittedly I was looking
> at a fairly specific case (i.e. squid :).
>
> Michael.
>