That's the important part.
> Linux does *NOT* implement kernel threads in the sense that its
> scheduler equates a "task" (a traditional Unix process) with a
> "thread".
Sure it does. (A task is not necessarily a "traditional Unix process".)
To avoid confusion, I recommend the following terminology:
task -- a "context of execution". (That is, one task structure being
scheduled.)
process -- a task that has been clone()d with COPYVM.
thread -- a task that has been clone()d without COPYVM.
Each kernel thread has it's own task struct -- therefore, they are
tasks. The scheduler only deals with tasks, which I think we can
appreciate: that's pretty elegant. A full-blown process adds its own
page tables (but not necessarily its own pages -- they are shared
with the parent until written to, which is another stroke of elegance).
> 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.)
> [Scheduling model and multiprocessor hardware]
> [Dynamically loadable schedulers]
> I have had no enthusiastic feedback from anyone on the list, and right
> now, I'm busy with another fairly ambitious Linux project, so its on the
> backburner for now, but once 2.2 comes out, and stuff like this might get
> more attention, I'll focus on it again.
Dynamically-loadable schedulers? That sounds like a snazzy project!
(Enthusiasm! Enthusiasm! :)
However, I do find some code in 2.0.36 that appears to support
tasks "spiking" themselves on a particular processor:
#ifdef __SMP__
[...]
#ifdef PAST_2_0
/* This process is locked to a processor group */
if (p->processor_mask && !(p->processor_mask & (1<<this_cpu))
return -1000;
#endif
#endif
linux/kernel/sched.c, in goodness() -- there's also some other goodness in
goodness(), so take a look. :)
I'm starting to quote "#ifdef __SMP__", so I suspect we should
continue this discussion on the linux-smp list. However, I'll point
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.
But that is beside the point: Linux has kernel threads, and they have
been supported in commercial distributions since May, 1998 (at least --
probably earlier.)
I've written the author of that awful article. That author is an
acquantance of a good friend of mine -- the same friend who brought the
article to my attention. I'll report Dr. Russinovich's response (if
any).
Thanks to folks who gave me much-needed feedback!
-Scott
-
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/