> For some loads poll/select are actually extremely efficient. X clients
> batch commands up and there is a cost to switching between tasks for
> different clients. Viewed as an entire system you actually get quite
> interesting little graphs, especially in the critical load cases where
> select/poll's batching effect makes throughput increase rapidly at 100%
> CPU load, even if it gets you there far too early. Ditto with
> webservers.
Indeed, poll/select are very nice APIs and you definitely want to use them
if your apps does not need certain requirements. If N/M approaches 1, poll
scales exactly (alomst) like epoll. But poll does not born to scale on
huge number of fds, and this is recognized by ages. Yesterday I pulled out
a Mogul paper where (a long time ago) he talks about poll limits and he
also talks about three ideal APIs to deal with networking load :
declare_interest == epoll_ctl(EPOLL_CTL_ADD)
revoke_interest == epoll_ctl(EPOLL_CTL_DEL)
dequeue_next_events == epoll_wait()
This a long time before epoll :)
- Davide
-
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/