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    [from the cache]
©2003-2011 Jasper Spaans