[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

    On Fri, 2 Feb 2007, Alan wrote:
    > 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".

    Also, with sane default limits of fibrils per process (say, in the 5-10),
    it also ends up beign good for IO. No "insane" IO bombs, but an easy way
    for users to just just get a reasonable amount of IO parallelism without
    having to use threading (which is hard).

    So, best of both worlds.

    Yes, *of*course* you want to have limits on outstanding work. And yes, a
    database server would set those limits much higher ("Only a thousand
    outstanding IO requests? Can we raise that to ten thousand, please?") than
    a regular process ("default: 5, and the super-user can raise it for you if
    you're good").

    But there really shouldn't be any downsides.

    (Of course, there will be downsides. I'm sure there will be. But I don't
    see any really serious and obvious ones).

    > Other minor evil. If we use fibrils we need to be careful we
    > know in advance how many fibrils an operation needs so we don't deadlock
    > on them in critical places like writeout paths when we either hit the per
    > task limit or we have no page for another stack.

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

    Once a fibril has been created, it will *never* depend on any other fibril
    resources ever again. At least not in any way that any normal non-fibril
    call wouldn't already do as far as I can see.

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