Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: RasterMan on linux and threads | Date | Fri, 17 Dec 1999 10:16:30 -0800 |
| |
> Nope. He just doesn't know anything about scheduling (or threading). > 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 > process data is in the processor cache for all threads to share > without cache misses).
That assumes that the two threads are sharing a lot of changing context data. If that were true, no other method will be more efficient than multithreading. Shared memory, for example, will be no more efficient.
> It also means that other processes suffer, > because your one multi-threaded process (in the case of 2-way SMP) > would get twice as many context switches (each thread would need to > get swapped in and out seperately per processor),
If you care about performance, you shouldn't care about this. High-performance news servers don't worry about starving a web serving program. High-performance name servers don't worry about starving a mail program. Again, the alternative (multiple processes) would cause the same problem.
> and introduces lots > of luvverly atomicity nasties, because process data (visible to all > threads) needs to be available to all processors. Summary: Ouch.
Not so either. Caches handle shared unchanging data just fine.
Overall -- Nonesense. If you're considering multiple threads or multiple processors, multiple threads are a win all around.
1) You might have fewer context switches. A thread that can keep picking up whatever work happens to need to be done can run longer than a process that can only do work for a single connection/job.
2) You might have less expensive context switches. Thread context switches will require less work since the vm won't change.
3) You might be more responsive. In a multiprocess solution, an ambushed process will freeze whatever work was assigned to that connection. In a multithreaded solution, it will only stall the job that thread was doing -- other jobs can then be taken over by other threads.
There are several other factors that weigh in favor or threads, but these are probably the three biggest.
DS
- 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/
| |