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

    * Davide Libenzi <> wrote:

    > > my current thinking is that special-purpose (non-programmable,
    > > static) APIs like aio_*() and lio_*(), where every last cycle of
    > > performance matters, should be implemented using syslets - even if
    > > it is quite tricky to write syslets (which they no doubt are - just
    > > compare the size of syslet-test.c to threadlet-test.c). So i'd move
    > > syslets into the same category as raw syscalls: pieces of the raw
    > > infrastructure between the kernel and glibc, not an exposed API to
    > > apps. [and even if we keep them in that category they still need
    > > quite a bit of API work, to clean up the 32/64-bit issues, etc.]
    > Why can't aio_* be implemented with *simple* (or parallel/unrelated)
    > syscall submit w/out the burden of a complex, limiting and heavy API

    there are so many variants of what people think 'asynchronous IO' should
    look like - i'd not like to limit them. I agree that once a particular
    syslet script becomes really popular, it might (and should) in fact be
    pushed into a separate system call.

    But i also agree that a one-shot-syscall sys_async() syscall could be
    done too - for those uses where only a single system call is needed and
    where the fetching of a single uatom would be small but nevertheless
    unnecessary overhead. A one-shot async syscall needs to get /8/
    parameters (the syscall nr is the seventh parameter and the return code
    of the nested syscall is the eighth). So at least two parameters will
    have to be passed in indirectly and validated, and 32/64-bit compat
    conversions added, etc. anyway!

    The copy_uatom() assembly code i did is really fast so i doubt there
    would be much measurable performance difference between the two
    solutions. Plus, putting the uatom into user memory allows the caching
    of uatoms - further dilluting the advantage of passing in the values per
    register. The whole difference should be on the order of 10 cycles, so
    this really isnt a high prio item in my view.

    > Now that chains of syscalls can be way more easily handled with
    > clets^wthreadlets, why would we need the whole syslets crud inside?

    no, threadlets dont really solve the basic issue of people wanting to
    'combine' syscalls, avoid the syscall entry overhead (even if that is
    small), and the desire to rely on kthread->kthread context switching
    which is even faster than uthread->uthread context-switching, etc.
    Furthermore, syslets dont really cause any new problem. They are almost
    totally orthogonal, isolated, and cause no wide infrastructure needs.

    as long as syslets remain a syscall-level API, for the measured use of
    the likes of glibc and libaio (and not exposed in a programmable manner
    to user-space), i see no big problem with them at all. They can also be
    used without them having any classic pthread user-state (without linking
    to libpthread). Think of it like the raw use of clone(): possible and
    useful in some cases, but not something that a typical application would
    do. This is a 'raw syscall plugins' thing, to be used by those
    user-space entities that use raw syscalls: infrastructure libraries. Raw
    syscalls themselves are tied to the platform, are not easily used in
    some cases, thus almost no application uses them directly, but uses the
    generic functions glibc exposes.

    in the long run, sys_syslet_exec(), were it not to establish itself as a
    widely used interface, could be implemented purely from user-space too
    (say from the VDSO, at much worse performance, but the kernel would stay
    backwards compatible with the syscall), so there's almost no risk here.
    You dont like it => dont use it. Meanwhile, i'll happily take any
    suggestion to make the syslet API more digestable.

    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-02-28 10:55    [W:0.031 / U:3.360 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site