[lkml]   [1999]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Max tcp connections

> > 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.
> That seems to violateSuS. It has to report the state of all fd's. The
> API is the problem.

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:


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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.135 / U:3.564 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site