RE: Max tcp connections

David Schwartz (davids@webmaster.com)
Thu, 11 Nov 1999 18:28:59 -0800


> > 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.
>
> The wait queue add is about 30-40 clocks. It isnt the wait_queue add that
> is the issue, its the fact you are doing things for 30,000
> handles for every
> event on every handle (or at best every pending set of events)

Right, for every pending set of events. But as load goes up, so does the
size of each pending set of events.

Poll gives you more and more information as load goes up. Events do not.

> >
> > 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.
>
> My computer science lecturer would have put a red pen through
> that and marked
> it 0

It would help me more if you would explain why it is wrong rather than just
stating that it is wrong.

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/