Re: [PATCH 2 of 4] Introduce i386 fibril scheduling

From: Linus Torvalds
Date: Fri Feb 02 2007 - 16:30:47 EST




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.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/