[lkml]   [1999]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: RasterMan on linux and threads

> 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

> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean