Messages in this thread | | | Subject | Re: >256 fd patch... | Date | Mon, 24 Mar 1997 09:16:54 +0800 | From | "Michael O'Reilly" <> |
| |
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.
| |