[lkml]   [2003]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch][RFC] epoll and half closed TCP connections
    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.021 / U:9.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site