[lkml]   [2007]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0 of 4] Generic AIO by scheduling stacks
    > I looked at this approach a long time ago, and basically gave up  
    > because
    > it looked like too much work.

    Indeed, your mention of it in that thread.. a year ago?.. is what got
    this notion sitting in the back of my head. I didn't like it at
    first, but it grew on me.

    > I heartily approve, although I only gave the actual patches a very
    > cursory
    > glance. I think the approach is the proper one, but the devil is in
    > the
    > details. It might be that the stack allocation overhead or some other
    > subtle fundamental problem ends up making this impractical in the
    > end, but
    > I would _really_ like for this to basically go in.

    As for efficiency and overhead, I hope to get some time with the team
    that work on the Giant Database Software Whose Name We Shall Not
    Speak. That'll give us some non-trival loads to profile.

    > It won't matter at all for a certain class of calls (a lot of the
    > people
    > who want to do AIO really end up doing non-interruptible things, and
    > signalling is a non-issue), but not only is it going to matter for
    > some
    > others, we will almost certainly want to have a way to not just
    > signal a
    > task, but a single "fibril" (and let me say that I'm not convinced
    > about
    > your naming, but I don't hate it either ;)

    Yeah, no doubt. I'm wildly open to discussion here. (and yeah, me
    either, but I don't care much about the name. I got tired of
    qualifying overloaded uses of 'stack' or 'thread', that's all :)).

    > But from a quick overview of the patches, I really don't see anything
    > fundamentally wrong. It needs some error checking and some limiting (I
    > _really_ don't think we want a regular user starting a thousand
    > fibrils
    > concurrently), but it actually looks much less invasive than I
    > thought it
    > would be.

    I think we'll also want to flesh out the submission and completion
    interface so that we don't find ourselves frustrated with it in
    another 5 years. What's there now is just scaffolding to support the
    interesting kernel-internal part. No doubt the kevent thread will
    come into play here.

    - z
    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-01-30 23:51    [W:0.028 / U:18.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site