[SSI] Re: SSI-NUMA-MP

[Bruce W. <br...@ka...>]

Certainly would never flame someone who likes SSI
clusters,  but I'm going to side with Peter here, that there
are currently many flavors (or flavours) of 
interesting clusters.  Like JA, I think SSI
clusters are the most interesting and I am
chartered to work with the community to build
the best SSI cluster we can (leveraging HA
work, load leveling work, HP work etc.).  
If the SSI project is successfull, it may eventually
be the case that all current types of clusters use it
but it way to premature to assert that now.

What is useful now is something Alan and I (in our
own different ways) are trying to do, which is
provide some common framework/infrastructure that
clusters of differnt types can be built on.  I will
encourage that framework to be functional for an SSI
cluster, but not limited to one.  As such, we have
released some key pieces of infrastructure that we
hope others will optionally layer on top of (see the
CI project on www.opensource.compaq.com).

bruce

> Peter wrote:
> 
> --- "J . A . Magallon" <jam...@ab...> wrote:
> > Hi all...
> > 
> 
> > I think you should stop talking about anything 'to the right' of bproc.
> > Anything
> > that is based on knowledge by the programmer about his computer being a 
> > cluster (ie, be forced to message-passing style of life) is not a cluster for
> > me. There are tons of systems that do MP (MPI,PVM,Condor, etc). You (we)
> > should
> > think that a cluster is a multi-cpu system, just like a SMP box.
> 
> Do you mean that a collection of machines, connected by gigabit
> ethernet, and
> running Oracle Parallel Server (which means they share concurrent access
> to the
> storage) is not a cluster?  Or put DB2 there.  Or, your favourite
> database
> there.  In conjunction with additional components (i.e., HA software)
> the
> database maintains high availability (how high we've been debating :)
> and
> recovers from failures...
> 
> This is not a cluster?  Granted, Oracle/DB2/whatever know they're on
> separate
> machines (at least logically), and expect to do message passing.
> 
> Yes, you can also buy a big machine, and run a single Oracle/DB2 image,
> and
> have this one image failover to a second machine.  You are saying this
> also is
> not a cluster?  
> > 
> > MPI can be implemented on a SMP box just by running over SHM or local
> > sockets.
> > A threaded program can not be run on a COW. So if the system image is
> based
> > on
> > an SMP idea, the cluster can run MP programs easily. The reverse is
> much
> > harder,
> > if possible.
> 
> I've been involved in projects that allowed threaded programs to run on
> COWs. 
> They ran about as fast as cows (yes, bovines :) which means they're not
> all
> that interesting.  But it can be done, and it doesn't need SSI to do it.
> 
> > 
> > So a system with a single image should be the target. If you cant
> afford slow
> > disk
> > access, well, replicate the read-only file system parts (/usr) on each
> node.
> > If the cluster infrastructure just eases things for MPI, there is no
> kernel
> > change
> > needed. We should target on a global pid space, a global memory space.
> We
> > need
> > process migration.
> > 
> A system with a single image is one valid target.  Everything global
> places
> premiums on speed of networks, can be very intrusive on the kernel and
> potentially on applications, and requires some element of 'thinking
> differently.'  Note that I am not criticising the ideal, I would more
> than
> favour having such a system for those people who want it, but I don't
> like the
> idea of imposing it on everyone.
> 
> The second effect is the cost in system reliability due to the
> mechanisms added
> to try and achieve this.  That said, if we never try, we never succeed.
> 
> > I think the system really is one step beyond of NUMA boxes. You can
> program
> > based
> > on a shared memory interface if you want, and perhaps your program
> will not
> > be
> > the more efficient in the world. But it works.
> > 
> 
> It may work so poorly if your interconnects are slow (relative to the
> usage
> patterns of your program) that you won't want it.  A program that has a
> memory
> sharing pattern where two threads are constantly updating some shared
> pieces of
> storage are not necessarily good models for running remote to each
> other.  This
> is also true that such a program is not a good candidate for PVM usage
> either.
> 
> > -- 
> > J.A. Magallon                           #  Let the source be with
> you...     
> >   
> > mailto:jam...@ab...
> > Mandrake Linux release 8.1 (Cooker) for i586
> > Linux werewolf 2.4.6-ac5 #1 SMP Wed Jul 18 17:25:15 CEST 2001 i686
> > 
> 
> Peter
> 
> =====
> These have been the opinions of:
> Peter R. Badovinatz -- (503)578-5530 (TL 775)
> wo...@us.../tab...@ya...
> and in no way should be construed as official opinion of 
> IBM, Corp.
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
> 
> Linux-cluster: generic cluster infrastructure for Linux
> Archive:       http://mail.nl.linux.org/linux-cluster/