Messages in this thread | | | Date | Fri, 17 Dec 1999 14:45:33 -0800 | From | Dan Kegel <> | Subject | Re: RasterMan on linux and threads |
| |
raster@rasterman.com 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |