lkml.org 
[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > Re: Linux threads -- as seen in NT Magazine
As I am not by any means an expert at parallel programming, my example may
be totally wrong. I was just thinking that in some cases it would be
non-trivial (or even impossible) for the kernel to determine which
processors to run the threads on to accomplish the task in the shortest
amount of time, particularly when there are more threads in the process
than processors, and most particularly if multithreaded programs are not
recognized as such. Of course, some kind of mechanism may already exist
to handle this. I don't know. Does the kernel do process migration? If
not, here is what seems to me to be a good example: two computationally
intensive threads plus one fairly inactive thread. If the two intensive
threds are scheduled on the same processor, and the inactive one gets to
sit by itself, huge amounds of time could be wasted. I don't know what
mechanisms would be needed to solve this, but hints to the scheduler might
help. compatibility could be retained by something like
#ifndef hint
#define hint 0
#endif

or some better scheme.

On Tue, 15 Dec 1998, Richard Gooch wrote:

> Paul Barton-Davis writes:
> > >From: Richard Gooch <rgooch@atnf.csiro.au>
> > >Date: Sun, 13 Dec 1998 08:12:15 +1100
> > >Subject: Re: Linux threads -- as seen in NT Magazine
> > >
> > >David Feuer writes:
> > >> ***I think it would be _very_ good to make sure that threaded-pipeline
> > >> programs are run in a reasonable way (for example, it would probably not
> > >> be good if pipeline went 1-2-3, but 1 and 3 ended up on the same
> > >> processor).***
> > >
> > >If you have the processes blocking on each other, then they will be
> > >scheduled on the "right" processor. If the processes don't block then
> > >it shouldn't matter.
> > >If you think the current implementation isn't working, benchmark and
> > >analyse it to show us how.
> >
> > In the general case, the kernel cannot determine which N threads of a
> > set of M threads (where M > N) are the best to run at a given point in time.
> >
> > "best" here doesn't refer to goodness(), but to user-level application
> > performance. The pipeline David referred to may well be implemented
> > entirely at user-level, using UL spin-locks that are invisible to the
> > kernel. There is therefore no way for the kernel to ensure correct
> > scheduling. All it knows is that a thread called sched_yield(), but
> > has no idea why, or under what circumstances it might want to run
> > again.
>
> The spinlocks in LinuxThreads are a hybrid user/kernel entity. They
> (IIRC) first spin a few times, reschedule a few times, then they go to
> sleep. In the example cited above, why won't you get the desired
> behaviour with this mechanism?
>
> Process 1 unlocks process 3, then locks waiting for 3 to finish. When
> process 1 yields, process 3 will be run (since process 2 is on the
> other CPU).
>
> > All of this stuff is the standard UL vs. Kernel thread argument. Linux
> > doesn't solve it, rightfully so at the moment, but to pretend that the
> > current implementation is even close to "correct" for multithreaded
> > applications is a joke. Fortunately, it just so happens to work for
> > most of the time :)
>
> Certainly has for me :-)
>
> Regards,
>
> Richard....
>
> -
> 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/
>

________________
/ David Feuer \
| dfeuer@mbhs.edu |
| feuer@his.com |
\________________/


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.083 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site