Re: >256 fd patch...

Matthias Urlichs (smurf@noris.de)
20 Mar 1997 13:35:10 +0100

In linux.dev.kernel, article <x7ohcgweqj.fsf@metal.iinet.net.au>,
"Michael O'Reilly" <michael@metal.iinet.net.au> writes:
>
> Actually, this isn't a patch for > 256 FD's per se, what is does is
> have select() use tables that AREN'T allocated off the kernel stack,
> but malloc'ed instead. I'm using this for a machine running with 3000
> FD's per process. Hasn't fallen over yet....
>
Hmm. That's a lot, especially since most processes will not use that many.

> I'm running this on a production machine that's taking around 55,000
> TCP connection an hour into a pair of squid's (machine is a PPro 200,
> with 448Meg of ram, and 18 gig of disk).
>
Your patch will break on SMP machines (fds_index isn't used atomically).

If you do want the caching, your code gets cleaner if you do it this way:

Allocate:
if(index)
data = cache[--index];
else
data = malloc();

Free:
if(index < SIZE_OF_CACHE)
cache[index++] = data;
else
free(data);

but you'll have to do some SMP locking.

-- 
Overeat:  To dine.
                               -- Ambrose Bierce, "The Devil's Dictionary" 

-- 
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail: urlichs@noris.de
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="http://info.noris.de/~smurf/finger">here</A>.    42