Messages in this thread |  | | | Date | Mon, 6 Sep 1999 10:54:00 +0100 (GMT/BST) | | From | Mike Jagdis <> | | Subject | Re: > 15,000 Simultaneous Connections |
| |
On Mon, 6 Sep 1999, Steve Underwood wrote:
> So, the solution is to fix the clunky design of select, right? I'm not convinced > that dealing with a huge number of threads is any better than scanning a huge > select, anyway. Especially on a processor like the x86, which has scanning > instructions that can be used to scan the list quite quickly.
You might be able to scan fdsets quickly at the user level but internally select has to scan the list and call the check routine for every interesting descriptor. I've been working on the kernel implementation of select/poll and can tell you that if a one descriptor select takes 40-50 *micro*seconds a 1000 descriptor select will be up in the region of 8-10 *milli*seconds (on my 6x86 P150+).[1]
The current select/poll implementation can be improved significantly, especially in the blocking case, but the overhead will still increase with the number of descriptors because select/poll does not, and cannot, remember what descriptors are interesting. This would be easy to fix with a new API. Suggestions are welcome - particularly from people who might actually be interested in using it in earnest.
Mike
[1] Pictures and patches would be on my web site had it not been such a nice weekend :-).
-- A train stops at a train station, a bus stops at a bus station. On my desk I have a work station... .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 2 Markham Mews, Broad Street | Telephone: +44 118 989 0403 | | Wokingham ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |