lkml.org 
[lkml]   [2007]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > With cooperative scheduling (like the example Zach posted), there is
    > absolutely no "brown and sticky" wrt any CPU usage. Which is why
    > cooperative scheduling is a *good* thing. If you want to blow up your
    > 1024-node CPU cluster, you'd to it with "real threads".

    i'm not worried about the 1024-node cluster case.

    i also fully agree that in some cases /not/ going parallel and having a
    cooperative relationship between execution contexts can be good.

    but if the application /has/ identified fundamental parallelism, we
    /must not/ shut that parallelism off by /designing/ this interface to
    use the fibril thing which is a limited cooperative, single-CPU entity.
    I cannot over-emphasise it how wrong that feels to me. Cooperativeness
    isnt bad, but it should be an /optional/ thing, not hardcoded into the
    design!

    If the application tells us: "gee, you can execute this syscall in
    parallel!" (which AIO /is/ about after all), and if we have idle
    cores/hardware-threads nearby, it would be the worst thing to not
    execute that in parallel if the syscall blocks or if the app asks for
    that syscall to be executed in parallel right away, even in the cached
    case.

    if we were in the 1.2 days i might agree that fibrils are perhaps easier
    on the kernel, but today the Linux kernel doesnt even use this
    cooperativeness anywhere. We have all the hard work done already. The
    full kernel is threaded. We can execute arbitrary number of kernel
    contexts off a single user context, we can execute parallel syscalls and
    we scale very well doing so.

    all that is needed is this new facility and some scheduler hacking to
    enable "transparent, kernel-side threading". That enables AIO,
    coroutines and more. It brings threading to a whole new level, because
    it makes it readily and gradually accessible to single-threaded apps
    too.

    [ and if we are worried about the 1024 CPU cluster (or about memory use)
    then we could limit such threads to only overlap in a limited number,
    etc. Just like we'd have to do with fibrils anyway. But with fibrils
    we /force/ single-threadedness, which, i'm quite sure, is just about
    the worst thing we can do. ]

    Ingo
    -
    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-02 23:55    [W:4.160 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site