lkml.org 
[lkml]   [1998]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: SMP scalability: 8 -> 32 CPUs
Date
For a good overview of the challenges associated with getting good
performance out of multiple processors (SMPs and clusters), see "In Search
of Clusters" by Gregory F. Pfister. I bought it a year ago when the first
edition hit and then later got the second edition. It's a good book written
by a guy who worked at IBM's Watson Research Facility.

It turns out that neither memory or I/O is the real reason that you can't
get good performance from multiple processors. It's the programs! Some
problems are hard to solve in anything but a serial fashion so adding
processors doesn't help. Some programs (like databases) access certain
portions of data frequently, so you have collisions between the processors
all trying to access the same data, etc. There are whole buckets of
reasons. They basically fall into serialization, memory coherence, and
overhead (granularity) associated with propogating updates to data shared by
multiple processors.


> -----Original Message-----
> From: owner-linux-kernel@vger.rutgers.edu
> [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Kurt Garloff
> Sent: Saturday, November 28, 1998 4:37 AM
> To: Eloy A. Paris; linux-kernel@vger.rutgers.edu
> Subject: Re: SMP scalability: 8 -> 32 CPUs
>
>
> 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/
>


-
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:45    [W:0.483 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site