[TriLUG] Questions about Threading
Jeremy P
jeremyp at pobox.com
Tue Mar 26 12:50:34 EST 2002
On Tue, 26 Mar 2002, Jeff Bollinger wrote:
> I'm not a programmer, but I am curious about threading and the
> advantage to having a multi-processor linux box (I guess running an
> smp kernel). Do programs have to be written to take advantage of a
> dual-processor, or will cycles be distributed evenly during a process?
> How do you know if your program will support multiple processors?
This is my general, non-programming understanding of this; hopefully
someone can correct any misconceptions.
Programs can be written to take direct advantage of multiple processors,
but as far as I know, most for Linux don't. There seems to be some
argument about different threading models, and until that's sorted out, we
probably won't see much multithreaded stuff. The problem is that these
things are very different among the Unix platforms, and most open source
projects want their software to work on Linux, Solaris, BSD, etc. -- and
each has very different systems for multithreaded processes.
My understanding is that "symmetric" multi-processing, the S in SMP,
implies that each heavyweight (non-threaded) process is assigned to a
given processor. If a computer only runs one single-process program, this
does you no good. But since programs like Apache often use many
sub-processes, the scheduler distributes the load pretty evenly by
assigning some to one processor, and some to another. Also, the kernel
apparently can easily switch the processes around to balance the load.
If you run "top" on a multi-processor system, you can monitor this; on a
loaded system the CPU% will add up to n*100%, with 100% for each
processor.
Linux used to be fairly slow at SMP, although I think that's been vastly
improved in the 2.4 kernels. If you don't run the smp kernel, your
system will only use the first processor, of course.
Another neat aspect of multiprocessor systems is that if a process gets
out-of-control and monopolizes 100% of the CPU, you've got another CPU to
work with. The system will still be fully reponsive (the scheduler will
assign all processes to the remaining, non-monopolized CPU), and you can
go in and kill the errant process. On a uniprocessor system an
out-of-control process can make the system totally unresponsive, depending
on the situation.
--Jeremy
More information about the TriLUG
mailing list