Messages in this thread | | | Date | Fri, 21 Mar 1997 14:55:10 -0500 (EST) | From | Floody <> | Subject | Re: >256 fd patch... |
| |
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 21 Mar 1997, Theodore Y. Ts'o wrote:
> 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.....
Quite a few nanoseconds though. Light only travels around 1.5 feet in a nanosecond you know. :-)
Flood "Wow, my telnet connection to Mars is *really* lagged this time of year!".
+-------------------------------------------------------------------+ + -- Finger: flood@evcom.net for my PGP public key -- + +-------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE----- Version: 2.6.2
iQCVAwUBMzLnoBsjWkWelde9AQGqMwQAnVsqaLnuiMV58BgoXemQYjOvZyteB4IZ cbIhXvaIQgfGzUgd78iQjJbkYDXOM13xAFeSdmQCCZY0jqYm66SP4vVvdXCGQHl+ 71iKhE3SCvQsacaWNXYTTa0WwFsMKZhNFU0aT3CKlF0P+sbyhmxd/iM0Xxp3cUth gFo1ylFi8Tc= =o9I4 -----END PGP SIGNATURE-----
| |