[lkml]   [2007]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
    > > The brown and sticky will hit the rotating air impeller pretty hard if you
    > > are not very careful about how that ends up scheduled
    > Why do you think that?
    > 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".

    You end up with a lot more things running asynchronously. In the current
    world we see a series of requests for attributes and hopefully we do
    readahead and all is neatly ordered. If fibrils are not ordered the same
    way then we could make it worse as we might not pick the right readahead
    for example.

    > Since we'd only create fibrils on a system call entry level, and system
    > calls are independent, how would you do that anyway?

    If we stick to that limit it ought to be ok. We've been busy slapping
    people who call sys_*, except for internal magic like kernel_thread
    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-02 23:41    [W:0.019 / U:18.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site