owner-linux-kernel-digest@vger.rutgers.edu wrote:
> lFrom: Paul Barton-Davis <pbd@Op.Net>
> Date: Tue, 08 Dec 1998 15:53:40 -0500
> Subject: Re: Linux threads -- as seen in NT Magazine
>
> Well, lets get a few things clear.
>
> Linux does implement kernel threads via the clone(2) interface. This
> allows lightweight creation of a new execution context, and is
> actually much more flexible than either NT or Solaris' kernel thread
> creation interface, since userspace can dictate exactly which parts of
> the parent execution context are shared. Its very fast, and very
> usable, as the POSIX-conformant Linuxpthreads library demonstrates.
>
> Linux does *NOT* implement kernel threads in the sense that its
> scheduler equates a "task" (a traditional Unix process) with a
> "thread". 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.
>
> Therefore, kernel scheduling *is* indeed blind to the idea of a
> multithreaded application, and operates on the assumption (which is
> actually OK much of the time) that scheduling every kernel thread
> independently is the thing to do.
>
> However, its far from always the right thing to do. The current
> scheduling model cannot offer proper support to applications that want
> to explicitly take advantage of multiprocessor hardware, because it
> has no idea that task N and task M actually "belong" to the same
> application.
>
> As I've previously mentioned here, I've done some work on changing
> this, albeit as part of a more ambitious project to implement
> dynamically loadable schedulers. I often run a kernel on my machine
> that *does* consider kernel threads to belong to a "group", and offers
> them the chance to schedule themselves as they see fit. 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.
>
> - --p
>
Greetings,
Just wanted to let you know that the threads features that you descibe, would be very useful to myself, and our
software team. When you get to the point of needing testers, please let me know.
Steve Suson
"Keep the faith."
--------------A7FF8CC549504708C9076269
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
owner-linux-kernel-digest@vger.rutgers.edu wrote:
lFrom: Paul Barton-Davis <pbd@Op.Net>Greetings,
Date: Tue, 08 Dec 1998 15:53:40 -0500
Subject: Re: Linux threads -- as seen in NT MagazineWell, lets get a few things clear.
Linux does implement kernel threads via the clone(2) interface. This
allows lightweight creation of a new execution context, and is
actually much more flexible than either NT or Solaris' kernel thread
creation interface, since userspace can dictate exactly which parts of
the parent execution context are shared. Its very fast, and very
usable, as the POSIX-conformant Linuxpthreads library demonstrates.Linux does *NOT* implement kernel threads in the sense that its
scheduler equates a "task" (a traditional Unix process) with a
"thread". 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.Therefore, kernel scheduling *is* indeed blind to the idea of a
multithreaded application, and operates on the assumption (which is
actually OK much of the time) that scheduling every kernel thread
independently is the thing to do.However, its far from always the right thing to do. The current
scheduling model cannot offer proper support to applications that want
to explicitly take advantage of multiprocessor hardware, because it
has no idea that task N and task M actually "belong" to the same
application.As I've previously mentioned here, I've done some work on changing
this, albeit as part of a more ambitious project to implement
dynamically loadable schedulers. I often run a kernel on my machine
that *does* consider kernel threads to belong to a "group", and offers
them the chance to schedule themselves as they see fit. 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.
Just wanted to let you know that the threads features that you descibe, would be very useful to myself, and our software team. When you get to the point of needing testers, please let me know.
Steve Suson
"Keep the faith."
--------------A7FF8CC549504708C9076269--
-
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/