In article <slrnf19kpo.524.mykleb@lc4eb6380248654.ibm.com>,
Jan-Frode Myklebust <mykleb@no.ibm.com> writes:
|>
|> I believe these cluster control processes will have a negligble
|> impact (*). It's the applications you'll be running that will decide
|> if you should use SMT or not. We let the users decide on a job
|> by job basis if they want SMT by specifying this in their LoadLeveler
|> scripts, and then have LL pre/post scripts turn on/off SMT

Don't you believe it :-(

The way that they have an impact is by disturbing the scheduling; if
your applications, communications methods and scheduler get on well
together, there won't be a problem. But, if the aggregate system is
a bit sensitive, you can get some very strange effects. This applies
as much to SMT as it does to distributed memory clusters.

In extremis, you can get deadlock, livelock and massive performance
degradation (I observed a factor of over 1,000 on a POWER3 running
AIX, and have seen pretty bad ones on other (non-IBM) systems). This
is rare, but changing an apparently irrelevant confuguration parameter
is often the way to 'cure' it.


Regards,
Nick Maclaren.