Re: >256 fd patch...

Theodore Y. Ts'o (tytso@MIT.EDU)
Fri, 21 Mar 1997 12:16:21 -0500


Cc: submit-linux-dev-kernel@yggdrasil.com
Date: Fri, 21 Mar 1997 12:20:15 +0800
From: "Michael O'Reilly" <michael@metal.iinet.net.au>

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.

This is called false optimization; checking to see if there were less
than 32 file descriptors takes exactly one comparison; at worst you
might need another comparison at the end of select() to determine
whether or not you need to free fd_sets. So we're talking about two
jumps, and possibly two pipeline stalls, at worst.

The code might get a little bit bigger, but select() isn't in a tight
loop, so it's not like there are going to be any cache effects by
spreading out the code a little.

Most importantly, select() isn't critical path code!!! If the execution
time of select gets increased by (say) 20 or 40 cycles, no one is going
to be able to notice the difference. We're talking nanoseconds
here.....

- Ted