Date: Tue, 21 Dec 1999 15:55:18 PST From: Jason Nordwick <nordwick@xcf.berkeley.edu> To: Jonathan Lemon <jlemon@americantv.com> Cc: cmsedore@maxwell.syr.edu, hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <19991222234853.5770.qmail@scam.xcf.berkeley.edu>
next in thread | raw e-mail | index | archive | help
Return-Path: <nordwick@erdos.hq.askjeeves.com>
In-Reply-To: Your message of "Tue, 21 Dec 1999 09:22:04 CST."
<199912211522.JAA04702@free.pcs>
----
>>In my case, load is reasonably distributed. Is poll() really that much
>>better than select()? I thought that, excepting bit flag manipulations,
>>it worked basically the same way on the kernel end.
>
>Yes, it is better. Select uses the same backend as poll(), but those
>"bit flag manipulations" that you are talking about consume a measurable
>amount of CPU time when you start throwing thousands of descriptors at it.
>--
>Jonathan
>
I cannot believe that this is true. It would seem, to me, that it is highly
dependant on the density of the interest bit vector of select(). If it is
very dense, then select is more appropriate. Obviously, if you are only
interested in fd# 5 and fd# 1000, then, yes, there is unecessary scanning.
However is you are interested in 90% of the descriptors from 5 to 1000, then
all the scanning is necessary. (you can also, obviously, look through 32
descriptors at a time).
Also, doesn't the kernel need to copy the argument arrays into kernel space.
A struct pollfd is 8 bytes per interested descriptor, whereas, select() only
needs 1 bit per interested descriptor. If I am interested in 1000 descriptors
(assuming in a row), that is 8000 bytes to copyin, versus 125 bytes.
Can somebody who knows better explain, please?
-jason
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991222234853.5770.qmail>