[lkml]   [1999]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RasterMan on linux and threads wrote:
> On 17 Dec, Brian Pomerantz scribbled:
> -> Basically when you start a thread, the likelihood of it running on
> -> another CPU than the one the original process is running is small if
> -> the thread is short lived. The reason for this is the scheduler gives
> -> priority to a process on the same CPU as the one currently running and
> -> more priority if that process shares the same VM as the one that was
> -> just running. If a thread lives long enough or there is a large
> -> number of threads sharing the same VM, eventually it/they will migrate
> -> across more CPUs. Threads are no different than processes in this
> -> regard.
> thqats what i was lead to believe - for all practical purposes if you
> have a api library that goes and for short bursts creates and destroys
> threads to try and speedup a chrunching-heavy inner loop by spliting it
> into segments and having different threads handle each segment - then
> it wont get scheduled across multiple processors - if this is he case
> si there a way to force it (so i can at lats get benchmarks as i can
> pretty much be sure it ont give any speedup on a UP box)

Brian's post suggests a way to get a thread to run on another processor:
make it long-lived. Try finding a spot in your architecture where
creating just *one* extra thread, hooked up to the rest of the code
by a queue, makes sense. That will let you overlap that part of your
pipeline with the rest without adding too much overhead. After a
while, it will naturally migrate to the other processor, if Brian
is right.

It's not clear there is always a sensible place to break things off
into a worker thread. Carmack tried to find a way to speed up his
rendering by adding one, I think, but gave up. (Can't find it in
his .plan; maybe it was May or June '99)
- Dan

(The above is just my personal opinion; I don't speak for my employer,
except on the occasional talk show.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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