David Schwartz wrote:
> But so does 'poll'. If you double the number of active and inactive
> connections, 'poll' takes twice as long. But you do twice as much per call
> to 'poll'. You will both discover more connections ready to do work on and
> move more bytes per connection as the load increases.
Well, with that assumption sure there is nothing _to_ scale - poll and
select are perfect.
> > That was always the complaint about select() and poll(): they dominate
> > the run time for large numbers of connections. epoll, on the other
> > hand, will always be in the noise relative to other work.
>
> I think this is largely true for Linux because of bad implementation of
> 'poll' and therefore 'select'.
It's true those implementations could use clever methods to reduce the
amount of time they take by caching poll results, and probably
approach epoll speeds.
However their APIs have a built-in problem - at minimum, the kernel
has to read & write O(N) memory per call.
With your assumption of a fixed ratio of active/idle sockets, and
where that ration is not very small (10% is not very small), of course
the API is not a problem.
> > If you want a formula for slides :), time_polling/time_working is O(1)
> > with epoll, but O(N) with poll() & select().
>
> It's not O(N) with 'poll' and 'select'. Twice as many file descriptors
> means twice as many active file descriptors which means twice as many
> discovered per call to 'poll'.
It is O(N). When the load pattern follows your example, O(N) == O(1) :)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:49 EST