Re: >256 fd patch...
Michael O'Reilly (michael@metal.iinet.net.au)
Fri, 21 Mar 1997 12:20:15 +0800
In message <9703201627.AA20113@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes:
> I thought about that, but couldn't see a major win with it. The select
> code is already only copying FD's <= n, so the rest of the memory
> allocated is going unused, but other than that...
>
> I found that on my big machine, the caching of the last 10 kmallocs
> was to little. It actually had up to 24 select()'s sleeping at one
> time, so I increased the cache to 100 elements.
>
> Of course, this has negative implications for memory usage....
>
> Yes, but how many of the selects were using more than 32 file
> descriptors? If most of them are using less than 32, then using the
> statck for those cases *would* be a major memory win.
Ahh yes. It would be a major memory win (very few of them were using
more than 32 fd's), but from my point of view it would complicate the
patch, and slow it down. I belive it's more suited to be a kernel
compile option, than a permenant place in the kernel.
Michael.