Re: >256 fd patch...
Michael O'Reilly (michael@metal.iinet.net.au)
Mon, 24 Mar 1997 09:16:54 +0800
In message <9703211716.AA20588@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes:
> 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.
Ok. point taken. :)
> 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.....
Hmm. I've a machine that's calling select around 3000 times per
second... For me, select is very nearly critical path code.
Michael.