Re: SMP scalability: 8 -> 32 CPUs

Kurt Garloff (garloff@kg1.ping.de)
Sat, 28 Nov 1998 10:37:07 +0100


On Sat, Nov 28, 1998 at 12:50:03AM +0000, Eloy A. Paris wrote:
> Guys, excuse my ignorance, but does anyone know why Linus said in his
> last Linux Journal interview that right now it is fairly unrealistic
> to expect scaling from 8 to 32 CPUs? What's stopping Linux to scale in
> terms of CPUs?

Basically there are different mechanisms which limit the speed of operation:
(1) CPU(s) speed
(2) Memory speed (and size)
(3) I/O (Network, HD, VGA, ...)

By increasing the number of CPUs, you only do something about (1). So only
CPU bound processes may profit.

If you have a large number of independent CPU bound processes, they will
scale very nicely until they altogether hit the Memory or I/O bound.

If it's only one process, you're interested in, you have to do
multithreading, to have a scalability. In most applications, the threads
have to synchronize at or communicate certain points (e.g. before accessing
crititcal shared data), and with the number of CPUs, the synchronization
overhead is also increased. So the performance increase isn't linear.

If you do number crunching and you are able to parallelize things very well,
without too much synchronization, and you don't have too high Memory or I/O
loads, then Linux will scale nicely with a large number of CPUs.

The PC hardware doesn't provide the means to decouple memory or I/O requests
nicely for a large number of CPUs, so you will hit the limit some time. The
CPUs, eg., have to keep their caches coherent, e.g., so you shouldn't
access the same memory from different CPUs, as this will result in
invalidated cache states.
This might be different on other hardware which provides some better
mechanisms for this ...

Regards,

-- 
Kurt Garloff <K.Garloff@ping.de>  (Dortmund, FRG)
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff

The second clause "open source code of derivative works" has been the most controversial (and, potentially the most successful) aspect of CopyLeft licensing. -- Halloween Document

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