> This is incorrect. Poll is a rather dumb design, as it fails to remember anything
> useful, and forces extensive searches. On the other hand, select only requires that
> you generate the appropriate offset into a bit array to check if an fd is of interest
> - much faster.
At the user level, yes. The kernel has to do extensive searching
and checking for both select and poll. This tends to overshadow
the user level overhead.
> The problem is that select is now emulated through poll,
Is it? On my system (glibc 2.0.7) select invokes fs/select.c:sys_select
and poll invokes fs/select.c:sys_poll. The only commonality between
the two is the per-descriptor check functions that are called.
> the total dumbness of the two! Neither poll nor select was well designed, but poll is
> much dumber than select.
I don't think either were designed when massive fd sets were
possible :-).
> poll takes far too much RAM, too. A 15K fd poll would
> consume over 100K just for the list of fds.
Worse, the current implementation uses kmalloc to get a kernel buffer
big enough for the full list. For more than 512 fds you're asking
for multiple, continuous pages. Select goes beyond a page at something
approching 5500 fds.
> I think the sane scheme would be a call like select, but with separate request and
> response lists. It would probably drop the exception option, since it is nearly
> useless anyway. It might (just might) add further selection lists akin to the other
> options in poll.
The main cost of select and poll, on the kernel side, is scanning
the fds to see what is ready. The way select and poll are usually
used we want a means to express an interest in an fd and then
receive a stream of "events" as fds change state.
Mike
--
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/