> 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/