Messages in this thread | | | From | "Sean Hunter" <> | Date | Fri, 17 Dec 1999 13:50:05 +0000 | Subject | Re: RasterMan on linux and threads |
| |
On Fri, Dec 17, 1999 at 12:14:40PM +0100, Borek Lupomesky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 17 Dec 1999, Sean Hunter wrote: > > > Moving a thread to a different processor is almost always a loss in > > the real world (ie except for very long-lived threads with one thread > > per proc on an otherwise idle box), because it means that not only do > > you have the cost of migrating the process to the other processor, but > > you lose cache-affinity (you need to save and restore as much context > > as seperate processes whereas if they share a processor, all the > > ... > > Well, OK, but this is quite a fundamental issue. I'm likely not getting > you very well -- do you mean, that when I run two threads process, both of > the threads will be run on same CPU (on MP, that is)? In other words, > threading doesn't take advantage of MP machines?
Threading does take advantage of MP inasmuch as other processes can run on the other CPU. The threads of a single process schedule faster on the same CPU schedule faster than they would if they were run on seperate cpus, and run "in parallel" in the same way that seperate processes do on UP. A lot of OSs got this wrong when threading first became the vogue, and now tout this as a feature, when its a performance loss. Linux has this 100% right.
Don't believe what you read in books about this either. If cache affinity (and the process memory shared between threads) isn't important to your application, then your app should probably not be threaded, but rather take the form of multiple seperate processes (a la qmail). These can easily and profitably be scheduled on seperate CPUs (Although gang-scheduling means that they should probably still have strong processor affinity also).
Migrating threads on to seperate CPUs is just one of those things that a lot of people seem to think should be a good idea, but if you do the benchmarks, you see it isn't.
If you need more info about this, Larry McVoy is the man. I believe he has written several papers about exactly these issues from his days at Sun. They're on his website (start at http://www.bitmover.com - I think that has a link to his personal papers).
Sean
- 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/
| |