Re: >256 fd patch...

Michael O'Reilly (
Mon, 24 Mar 1997 09:16:54 +0800

In message <9703211716.AA20588@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes:
> Cc:
> Date: Fri, 21 Mar 1997 12:20:15 +0800
> From: "Michael O'Reilly" <>
> 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.