Messages in this thread | | | Date | Fri, 17 Dec 1999 14:21:22 -0800 | From | Brian Pomerantz <> | Subject | Re: RasterMan on linux and threads |
| |
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.
BAPper
- 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/
| |