Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: Max tcp connections | Date | Fri, 12 Nov 1999 12:28:26 -0800 |
| |
> Hi, > > On Thu, 11 Nov 1999 17:18:57 -0800, "David Schwartz" > <davids@webmaster.com> said: > > > 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. > > Sure, it's well known that on busy internet servers, the number of fds > which are active at any point in time is likely to be only a fraction of > the total number.
It doesn't matter what that fraction is, so long as the fraction is constant with respect to the number of fds, my argument is still valid.
> The trouble is that you have a lot of slow links with > dropped packets on the internet --- it's not at all comparable to the > traffic profile on a LAN. Your connection table _will_ become dominated > by these slow connections for the simple reason that slow connections > linger longer than fast ones.
Exactly. Smart multithreaded programs move the 'busy' fds into one pollfd struct and the 'not so busy' fds into another. This way, the expensive poll call (the one with the most fds) is made as rarely as possible. However, this is a pain to do.
[snip] > You are O(n) in this case anyway for the simple reason that you need to > read and write each fd.
Exactly. No matter how good your event or poll logic is, you'll still have O(n) work to do. So if your notification mechanism is less than O(n), it will ultimately drop off into the noise. Poll, if properly implemented is less than O(n). Events, with an optimization to fall back to poll if there are 'too many' is less than O(n) too.
But the thing is, if events fall back to poll under high load, how can they be more scalable than poll? That strikes me as an absurd argument.
I am, however, convinced that events will use less CPU under low load. I am not convinced that events are any more scalable than poll.
> However, in real life, this simply doesn't > happen on the internet. The papers above estimated that at any point > only about 10% of their connections were live, and for any given poll() > only a fraction of those had new data to process. That is a _big_ > overhead for poll.
Even if the fraction is 1%, it's still a fraction. So it won't affect scalability. And, in fact, the longer it takes you to get back to 'poll', the higher this fraction will be. So from a scalability perspective, this is actually a benefit.
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/
| |