Linus has gone on record against classifying execution contexts into
threads, processes and so forth. I think he's right about that - Linux
has a very elegant model for creating new execution contexts, one that
is hard to explain with the traditional notions of "threads",
"processes" and so on.
However, I don't think that dealing only with tasks is very elegant. I
think it is a hangover from the pre-clone(2) days. It works well right
now because there are very few (any ?) multithreaded applications that
want to use MP hardware creatively. So, I think there is a very
elegant mechanism (clone(2)) that can be very elegantly used because
of schedule().
You should also keep in mind that fork() ("the full blown
process"-creator) is implemented using clone() as well.
>> There is no support in any current Linus-approved kernels
>> for the notion of a process ("task") that is implemented as a set of
>> kernel threads.
>
>I think I can understand why you'd want cooperating threads to be scheduled
>as a group. (It seems like you could take advantage of a processor's cache,
>as well as speed up a context shift.)
More than that. Suppose the application only ever wants to run when it
has 2 or more processors to schedule threads on.
>However, I do find some code in 2.0.36 that appears to support
>tasks "spiking" themselves on a particular processor:
That code has been significantly altered in 2.1. Now there is just a
fairly substantial hint to the scheduler that a task should remain on
the same CPU if possible. But there is no support that I can see for
requesting that a task bind itself to a processor. I plan to add this
soon, since I'm just building a dual processor where the "other"
PII/450 is intended to function like a DSP (thanks to a bound kernel
thread).
>out that it seems the benefits of dynamically-loaded schedulers could
>be gained with a single, highly-configurable scheduler, and that
>could preserve the elegance of the current implementation.
When people argue over the speedup of rearranging the layout of the
task struct to help improved cache line utilization allow a fraction
of a microsecond improvement in schedule(), I don't think there is
much hope of a run-time configurable scheduler. It might actually have
a branch instruction, and oh my, that *would* crucify performance. :)
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/