[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    On 3/2/07, Davide Libenzi <> wrote:
    > For threadlets, it might be. Now think about a task wanting to dispatch N
    > parallel AIO requests as N independent syslets.
    > Think about this task having USEDFPU set, so the FPU context is dirty.
    > When it returns from async_exec, with one of the requests being become
    > sleepy, it needs to have the same FPU context it had when it entered,
    > otherwise it won't prolly be happy.
    > For the same reason a schedule() must preserve/sync the "prev" FPU
    > context, to be reloaded at the next FPU fault.

    And if you actually think this through, I think you will arrive at (a
    subset of) the conclusions I did a week ago: to keep the threadlets
    lightweight enough to schedule and migrate cheaply, they can't be
    allowed to "own" their own FPU and TLS context. They have to be
    allowed to _use_ the FPU (or they're useless) and to _use_ TLS (or
    they can't use any glibc wrapper around a syscall, since they
    practically all set the thread-local errno). But they have to
    "quiesce" the FPU and stash any thread-local state they want to keep
    on their stack before entering the next syscall, or else it'll get

    Keep thinking, especially about FPU flags, and you'll see why
    threadlets spawned from the _same_ threadlet entrypoint should all run
    in the same pool of threads, one per CPU, while threadlets from
    _different_ entrypoints should never run in the same thread (FPU/TLS
    context). You'll see why threadlets in the same pool shouldn't be
    permitted to preempt one another except at syscalls that block, and
    the cost of preempting the real thread associated with one threadlet
    pool with another real thread associated with a different threadlet
    pool is the same as any other thread switch. At which point,
    threadlet pools are themselves first-class objects (to use the snake
    oil phrase), and might as well be enhanced to a data structure that
    has efficient operations for reprioritization, bulk cancellation, and
    all that jazz.

    Did I mention that there is actually quite a bit of prior art in this
    area, which makes a much better guide to the design of round wheels
    than micro-benchmarks do?

    - Michael
    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-03-02 22:25    [W:0.021 / U:190.620 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site