Messages in this thread | | | Date | Thu, 22 May 1997 21:24:59 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: general protection faults with 2.0.30 and filehandle patch |
| |
While you guys are tinkering with select() how about making it detect the min filehandle in addition to the max that it already detects. Then change the loop in do_select to go from min to max instead of 0 to max.
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. >
| |