Date: Wed, 22 Dec 1999 08:15:48 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Re: Practical limit for number of TCP connections? Message-ID: <99Dec22.080702est.40323@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Tue, 21 Dec 1999 09:22:04 -0600 (CST), Jonathan Lemon <jlemon@americantv.com> wrote: >In article <local.mail.freebsd-hackers/Pine.BSF.4.05.9912201950190.82375-100000@qwerty.maxwell.syr.edu> you write: >>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. I'm not as sure that it's that clear cut. poll(2) requires far more copyin/copyout than select(2) (8 bytes per fd instead of 1-3 bits/fd). And if it's the bit twiddling that you're worried about, the kernel has to check 10 bits in each pollfd entry, rather than the 1-3 bits for select(2). If you have a very sparse set of FD's to select on, then poll(2) should be better. I suspect the normal server case is closer to selecting on fds [3 .. nfds-1] - so select(2) is probably faster. poll(2) does have advantages over select(2): - Separate input-only and output-only fields mean you may not need to separately keep (or re-generate) the list of events of interest. - A wider range of states/events can be requested/reported. Has anyone done any timing comparisons between poll(2) and select(2)? Peter 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?99Dec22.080702est.40323>