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

[Jamie Lokier <jamie@shareable.org>]

David Schwartz wrote:
> 	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.

Ah, but as the fraction approaches 1, you'll find that you are
asymptotically approaching the point where you can't handle the load
_regardless_ of epoll overhead.

> 	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.

It scales according to the amount of work pending, which means that it
doesn't take any _more_ time than actually doing the pending work.
(This assumes you use epoll appropriately; there are many ways to use
epoll which don't have this property).

That was always the complaint about select() and poll(): they dominate
the run time for large numbers of connections.  epoll, on the other
hand, will always be in the noise relative to other work.

If you want a formula for slides :), time_polling/time_working is O(1)
with epoll, but O(N) with poll() & select().

-- Jamie