lm@bitmover.com (Larry McVoy) writes:
>I think this is worth repeating. When I was starting the clusters
>effort at Sun, it got cast as a "cluster-or-SMP" fight which was most
>unfortunate. You absolutely want to cluster SMPs - the SMP nodes provide
>you with a level of dynamic load balancing which is virtually impossible
>to get in a cluster of UP nodes.
>
>Do not think of clusters as "clusters on UPs" only - the people who want the
>highest performance will be clustering the most scalable SMP machines they
>can find.
I second this, I started to work with 2- and 4-CPU SGIs some years ago
and quickly learned to love how easy it was to smooth things out and get
good performance for the applications without having to work so hard with
all the CPU/IO balancing and juggling which is so typical for UP systems.
Now it feels hard to work on UP, I'm very tempted to get a 2-CPU PC as my
next workstation.
For the last year or so I have been working with IBM SP/2s, with from eight
to 16 nodes available for my stuff. The only way to use all that power
(which wasn't that much really, those SP/2s had big BIG problems with
price/performance) was to program for it and distribute different jobs on
different nodes. Compiling XEmacs took 50 minutes on a single node as
opposed to 2 minutes on a 4-CPU Power Challenge :-) (I didn't read about
Larry's `make cluster' until a couple of weeks ago.)
As far as the SP/2 is concerned it's just like having a bunch of computers
available on your local network, and the utilisation on each of them runs
into the same problems as any UP box. I really longed for the SMP SGIs
while working on the UP cluster SP/2.
My conclusion was exactly as Larry says above, because if each of those SP/2
nodes had been a two- or four-CPU SMP (with the SGI efficiency, mind you)
I'm certain I could easily have increased the total yield *more* than by just
two or four times. I'm not avare of what the latest SP/2s look like, are
Jason's 'clump' machines SMP clusters?
Clustering SMPs just makes a lot of sense. You should get the power without
the problems (in particular it's possible to avoid the SMP scaling problems).
- Tor
-
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/