lkml.org 
[lkml]   [2007]   [Feb]   [28]   [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 Wed, 28 Feb 2007, Ingo Molnar wrote:

    > * Davide Libenzi <davidel@xmailserver.org> wrote:
    >
    > > Did you hide all the complexity of the userspace atom decoding inside
    > > another function? :)
    >
    > no, i made the 64-bit and 32-bit structures layout-compatible. This
    > makes the 32-bit structure as large as the 64-bit ones, but that's not a
    > big issue, compared to the simplifications it brings.

    Do you have a new version to review?



    > > > But i'm happy to change the syslet API in any sane way, and did so
    > > > based on feedback from Jens who is actually using them.
    > >
    > > Wouldn't you agree on a simple/parallel execution engine [...]
    >
    > the thing is, there's almost zero overhead from having those basic
    > things like conditions and the ->next link, and they make it so much
    > more capable. As usual my biggest problem is that you are not trying to
    > use syslets at all - you are only trying to get rid of them ;-) My
    > purpose with syslets is to enable a syslet to do almost anything that
    > user-space could do too, as simply as possible. Syslets could even
    > allocate user-space memory and then use it (i dont think we actually
    > want to do that though). That doesnt mean arbitrary complex code
    > /should/ be done via syslets, or that it wont be significantly slower
    > than what user-space can do, but i'd not like to artificially dumb the
    > engine down. I'm totally willing to simplify/shrink the vectoring of
    > arguments and just about anything else, but your proposals so far (such
    > as your return-value-embedded-in-atom suggestion) all kill important
    > aspects of the engine.

    Ok, we're past the error code in the atom, as Linus pointed out ;)
    How about this, with async_wait returning asynid's back to a userspace
    ring buffer?

    struct syslet_utaom {
    long *result;
    unsigned long asynid;
    unsigned long nr_sysc;
    unsigned long params[8];
    };

    My problem with the syslets in their current form is, do we have a real
    use for them that justify the extra complexity inside the kernel? Or with
    a simple/parellel async submission, coupled with threadlets, we can cover
    a pretty broad range of real life use cases?



    - Davide


    -
    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-28 22:49    [W:3.427 / U:2.820 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site