[lkml]   [2006]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: async network I/O, event channels, etc
    From: Evgeniy Polyakov <>
    Date: Wed, 26 Jul 2006 10:28:17 +0400

    > I have not created additional DMA memory allocation methods, like
    > Ulrich described in his article, so I handle it inside NAIO which
    > has some overhead (I posted get_user_pages() sclability graph some
    > time ago).

    I've been thinking about this aspect, and I think it's very
    interesting. Let's be clear what the ramifications of this
    are first.

    Using the terminology of Network Algorithmics, this is an
    instance of Principle 2, "Shift computation in time".

    Instead of using get_user_pages() at AIO setup, we instead map the
    thing to userspace later when the user wants it. Pinning pages is a
    pain because both user and kernel refer to the buffer at the same
    time. We get more flexibility when the user has to map the thing

    I want us to think about how a user might want to use this. What
    I anticipate is that users will want to organize a pool of AIO
    buffers for themselves using this DMA interface. So the events
    they are truly interested in are of a finer granularity than you
    might expect. They want to know when pieces of a buffer are
    available for reuse.

    And here is the core dilemma.

    If you make the event granularity too coarse, a larger AIO buffer
    pool is necessary. If you make the event granuliary too fine,
    event processing begins to dominate, and costs too much. This is
    true even for something as light weight as kevent.
    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: 2006-07-27 08:13    [W:0.034 / U:38.524 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site