Messages in this thread | | | Date | Wed, 9 Dec 1998 07:36:44 -0800 | From | Scott Doty <> | Subject | Re: Linux threads -- as seen in NT Magazine |
| |
On Tue, Dec 08, 1998 at 03:53:40PM -0500, Paul Barton-Davis wrote: > Scott Doty quoted: > >The December issue of _Windows NT Magazine_ features an article: > >"NT vs. Unix." The article includes a sidebar "Linux and > >the Enterprise," which begins: > > > > Whereas Windows NT and all leading commercial operating systems > > (OSs) implement kernel-mode threads, Linux does not. > > Well, lets get a few things clear. > > Linux does implement kernel threads via the clone(2) interface.
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/
| |