[lkml]   [2007]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Syslets, Threadlets, generic AIO support, v6

    On Wed, 30 May 2007, Jeff Garzik wrote:
    > You snipped the key part of my response, so I'll say it again:
    > Event rings (a) most closely match what is going on in the hardware and (b)
    > often closely match what is going on in multi-socket, event-driven software
    > application.

    I have rather strong counter-arguments:

    (a) yes, it's how hardware does it, but if you actually look at hardware,
    you quickly realize that every single piece of hardware uses a
    *different* ring interface.

    This should really tell you something. In fact, it may not be rings
    at all, but structures with more complex formats (eg the USB

    (b) yes, event-driven software tends to use some data structures that are
    sometimes approximated by event rings, but they all use *different*
    software structures. There simply *is* no common "event" structure:
    each program tends to have its own issues, it's own allocation
    policies, and its own "ring" structures.

    They may not be rings at all. They can be priority queues/heaps or
    other much more complex structures.

    > To echo Uli and paraphrase an ad, "it's the interface, silly."

    THERE IS NO INTERFACE! You're just making that up, and glossing over the
    most important part of the whole thing!

    If you could actually point to something specific that matches what
    everybody needs, and is architecture-neutral, it would be a different
    issue. As is, you're just saying "memory-mapped interfaces" without
    actually going into enough detail to show HOW MUCH IT SUCKS.

    There really are very few programs that would use them. We had a trivial
    benchmark, the only function of which was to show usage, and here Ingo and
    Evgeniy are (once more) talking about bugs in that one months later.

    THAT should tell you something.

    Make poll/select/aio/read etc faster. THAT is where the payoffs are.

    In fact, if somebody wants to look at a standard interface that could be
    speeded up, the prime thing to look at is "readdir()" (aka getdents).
    Making _that_ thing go faster and scale better and do read-ahead is likely
    to be a lot more important for performance. It was one of the bottle-necks
    for samba several years ago, and nobody has really tried to improve it.

    And yes, that's because it's hard - people would rather make up new
    interfaces that are largely irrelevant even before they are born, than
    actually try to improve important existing ones.

    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: 2007-05-30 17:37    [W:0.042 / U:22.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site