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/