RE: SMP scalability: 8 -> 32 CPUs

Richard Solis (mail109988@pop.net)
Sun, 29 Nov 1998 12:10:29 -0500


Of course. But surely single app performance is a waypoint to multiple app
performance. And some of the lessons learned making the kernel usable by a
couple of processors on the same machine will help make the kernel scale to
two independant kernels running on two seperate machines but using the same
kernel data structures.

My opinion is that clustering will become the prefered method of scaling
performance. Communication between nodes is becomming fast enough to blur
the distinction between machines anyhow. The only missing piece (and it's a
big piece) is software written to use algorithms that minimize internal
serialization and maximize parallelizable threads.

> -----Original Message-----
> From: Gregory Maxwell [mailto:linker@z.ml.org]
> Sent: Sunday, November 29, 1998 1:06 PM
> To: Richard Solis
> Cc: Kurt Garloff; Eloy A. Paris; linux-kernel@vger.rutgers.edu
> Subject: RE: SMP scalability: 8 -> 32 CPUs
>
>
>
> Well.. The question was of Linux's SMP scalability in general, not just
> running a single app.. When running multiple differnt apps your
> bottlenecks are serialization in the kernel, and IO.
>
> On Sat, 28 Nov 1998, Richard Solis wrote:
>
> > 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.
>
>

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