The normal path is waiting, but the path that matters under load is not
waiting. Which is more important -- how little CPU you can use when you
aren't under load or how much load you can take?
At least, as soon as the first fd shows that it's ready for I/O, take us
off all the wait queues and stop putting us on them. But please stop blaming
the poll API for an implementation problem that is _not_ inherent in the
API.
> Signal based I/O is definitely the right approach for scaling
I still find this very hard to believe. How can one fast pass through poll
(assuming a smarter implementation) be less efficient than the OS sending me
5,000 signals? That strikes me as an incredible claim.
A properly implemented poll is less than O(n) (assuming we don't block).
The cost of the poll itself is O(n), but the higher the load, the fewer
times we call poll because it takes us longer to get back to it and we find
more active fds per poll.
A properly implemented signal based I/O will likely be O(n). If there are
10,000 connections each handing me one packet per second, I will need 10,000
signals per second. If the kernel is smart enough not to send me another
signal for the same connection if I haven't already processed the previous
one, isn't that likely to be >O(n) since each signal requires checking n
pending signals.
DS
-
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/