Re: RasterMan on linux and threads
raster@rasterman.com
Wed, 15 Dec 1999 19:57:12 -0500 (EST)
On 17 Dec, Brian Pomerantz scribbled:
-> On Wed, Dec 15, 1999 at 07:14:38PM -0500, raster@rasterman.com wrote:
-> >
-> > hmm - when did that change ? i thought that was the case and was baked
-> > up on hat asumtion by someone else a few weeks ago (primarily the
-> > reason being to make sure the threads share caches for speed reasons
-> > and to make sure cache concurrency issues are moe easiyl dealt with...
-> > well thats what i unerstood... i may be wrong (2.2 or 2.3 may have
-> > changed that)
-> >
->
-> 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)
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com
raster@enlightenment.org raster@linux.com
raster@zip.com.au
-
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/