[lkml]   [2009]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] observe and act upon workload parallelism: PERF_TYPE_PARALLELISM (Was: [RFC][PATCH] sched_wait_block: wait for blocked threads)

    On Mon, 16 Nov 2009, Linus Torvalds wrote:
    > Think of it like a classic user-level threading package, where one process
    > implements multiple threads entirely in user space, and switches between
    > them. Except we'd do the exact reverse: create multiple threads in the
    > kernel, but only run _one_ of them at a time. So as far as the scheduler
    > is concerned, it acts as just a single thread - except it's a single
    > thread that has multiple instances associated with it.

    Side note: before anybody asks why not do threads in user space to begin
    with, it's simple: IO, exceptions, and timers. All need kernel support.

    User-level threading works very well, and is usually efficient as hell.
    It's not that long since people constantly claimed that thread libraries
    in user space were much better, and tried to use complex NxM models to do
    them, exactly because user threads are so great.

    But almost nobody does user-level threading now, except for specific
    languages that are built around threading. Why? It's not because they
    don't work, it's because they have a few very annoying problems that make
    them not work at all for enough situations that it gets very painful. And
    it's usually about IO and system calls, but sometimes it's about page
    faults, and sometimes it's about the pain of multiplexing that annoying
    timer signal and all the crap that involves.

    So I'm suggesting that maybe we could look at doing kernel threads that do
    what user-level threading does. It sounds idiotic, and maybe it is - after
    all, traditionally one of the reasons for user-level threads is that you
    can avoid all the kernel overheads. But if we can make some really
    low-overhead "thread within a thread" model, maybe we could have close to
    the best of both worlds.

    Some people really want threads for multi-CPU workloads and spreading
    things out. That's what we have now. But other loads want threads for
    entirely different reasons, like just hiding IO latencies.


     \ /
      Last update: 2009-11-18 23:46    [W:0.636 / U:9.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site