lkml.org 
[lkml]   [2007]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3


    On Thu, 22 Feb 2007, Evgeniy Polyakov wrote:
    >
    > My tests show that with 4k connections per second (8k concurrency) more
    > than 20k connections of 80k total block in tcp_sendmsg() over gigabit
    > lan between quite fast machines.

    Why do people *keep* taking this up as an issue?

    Use select/poll/epoll/kevent/whatever for event mechanisms. STOP CLAIMING
    that you'd use threadlets/syslets/aio for that. It's been pointed out over
    and over and over again, and yet you continue to make the same mistake,
    Evgeniy.

    So please read that sentence ten times, and then don't continue to make
    that same mistake. PLEASE.

    Event mechanisms are *superior* for events. But they *suck* for things
    that aren't events, but are actual code execution with random places that
    can block. THE TWO THINGS ARE TOTALLY AND UTTERLY INDEPENDENT!

    Examples of events:
    - packet arrives
    - timer happens

    Examples of things that are *not* "events":
    - filesystem lookup.
    - page faults

    So the basic point is: for events, you use an event-based thing. For code
    execution, you use a thread-based thing. It's really that simple.

    And yes, the two different things can usually be translated (at a very
    high cost in complexity *and* performance) into each other, so people who
    look at it as purely a theoretical exercise may think that "events" and
    "code execution" are equivalent. That's a very very silly and stupid way
    of looking at things in real life, though.

    Yes, you can turn things that are better seen as threaded execution into
    an event-based thing by turning it into a state machine. And usually that
    is a TOTAL DISASTER, and the end result is fragile and impossible to
    maintain.

    And yes, you can often (more easily) turn an event-based mechanism into a
    thread-based one, and usually the end result is a TOTAL DISASTER because
    it doesn't scale very well, and while it may actually result in somewhat
    simpler code, the overhead of managing ten thousand outstanding threads is
    just too high, when you compare to managing just a list of ten thousand
    outstanding events.

    And yes, people have done both of those mistakes. Java, for example,
    largely did the latter mistake ("we don't need anything like 'select',
    because we'll just use threads for everything" - what a totally moronic
    thing to do!)

    So Evgeniy, threadlets/syslets/aio is *not* a replacement for event
    queues. It's a TOTALLY DIFFERENT MECHANISM, and one that is hugely
    superior to event queues for certain kinds of things. Anybody who thinks
    they want to do pathname and inode lookup as a series of events is likely
    a moron. It's really that simple.

    In a complex server (say, a database), you'd use both. You'd probably use
    events for doing the things you *already* use events for (whether it be
    select/poll/epoll or whatever): probably things like the client network
    connection handling.

    But you'd *in*addition* use threadlets to be able to do the actual
    database IO in a threaded manner, so that you can scale the things that
    are not easily handled as events (usually because they have internal
    kernel state that the user cannot even see, and *must*not* see because of
    security issues).

    So please. Stop this "kevents are better". The only thing you show by
    trying to go down that avenue is that you don't understand the
    *difference* between an event model and a thread model. They are both
    perfectly fine models and they ARE NOT THE SAME! They aren't even mutually
    incompatible - quite the reverse.

    The thing people want to remove with threadlets is the internal overhead
    of maintaining special-purpose code like aio_read() inside the kernel,
    that doesn't even do all that people want it to do, and that really does
    need a fair amount of internal complexity that we could hopefully do with
    a more generic (and hopefully *simpler*) model.

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-25 23:47    [W:0.024 / U:33.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site