No, continue checking state, but don't add to wait queues. I thought all
along that the reason poll was so inefficient was because you had to go on
O(n) wait queues only to be taken off of them if you don't block.
> > > 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.
>
> Benchmark it. Or for that matter just apply common sense. A signal
> delivery is O(1) with the number of events not O(N) (n=fdcount). A signal
> has wake one properties too.
Signal delivery is O(n) with respect to the number of connections. Poll is
O(1) (see below).
> People have tried this model. It works. VMS AST's are very
> similar in concept.
Poll is O(1) as well if implemented correctly. Consider the following loop:
while(1)
{
Poll();
Do_the_io_poll_found();
}
Now, poll itself is O(n), but doing the I/O is going to be O(n) (here n
represents the number of fds or clients). So we make a call that is O(n)
with a frequency that is O(1/n). Hence the overall overhead of poll is O(1)
with respect to the number of active connections. Signals can't touch that
scalability.
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/