RE: [Patch][RFC] epoll and half closed TCP connections

[David Schwartz]

> Look this is false for epoll. Given N fds inside the set and M hot/ready
> fds, epoll scale O(M) and not O(N) (like poll/select). There's a huge
> difference, expecially with real loads.
>
> - Davide

	For most real-world loads, M is some fraction of N. The fraction
asymptotically approaches 1 as load increases because under load it takes
you longer to get back to polling, so a higher fraction of the descriptors
will be ready when you do.

	Even if you argue that most real-world loads consists of a few very busy
file descriptors and a lot of idle file descriptors, why would you think
that this ratio changes as the number of connections increase? Say a group
of two servers is handling a bunch of connections. Some of those connections
will be very active and some will be very idle. But surely the *percentage*
of active connections won't change just becase the connections are split
over the servers 50/50 rather than 10/90.

	If a particular protocol and usage sees 10 idle connections for every
active one, then N will be ten times M, and O(M) will be the same as O(N).
It's only if a higher percentage of connections are idle when there are more
connections (which seems an extreme rarity to me) that O(M) is better than
O(N).

	Is there any actual evidence to suggest that epoll scales better than poll
for "real loads"? Tests with increasing numbers of idle file descriptors as
the active count stays constant are not real loads.

	By the way, I'm not arguing against epoll. I believe it will use less
resources than poll in pretty much every conceivable situation. I simply
take issue with the argument that it has better ultimate scalability or
scales at a different order.

	DS