In article <slrnf19o6f.594.mykleb@lc4eb6380248654.ibm.com>,
Jan-Frode Myklebust <mykleb@no.ibm.com> writes:
|>
|> What I meant to say was that these "cluster control processes"
|> will have a negligble impact on the decision to go for SMT on/off.
|> It's the application that matters.. But do of course get rid of
|> unneccessary disturbances (as mentiond in the (*)).

That's what I say is only USUALLY the case. The point about enabling
SMT (whatever form it takes) is that it is a very different and more
fine-grained form of parallelism than almost entirely separate cores.
In particular, it is much more likely to cause trouble to the basic
communication/synchronisation primitives if a control process and an
application one are scheduled on the same core than if they are not
(and, without SMT, they can't be).

This comes back to the old, old issue where some applications ran
perfectly well if run on the bare iron, but misbehaved as soon as you
put them under a monitor. Old problems never die - they merely go
into hibernation.

|> > 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.
|>
|> And doesn't it also apply as much to non-SMT ?

You mean non-SMT share memory? Of course. The POWER3 was, and so were
two of the other systems on which I saw serious problems. It applies
to ANY close-coupled, thread-based design.


Regards,
Nick Maclaren.