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

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

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2011 Jasper Spaans