Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-08-17 08:40:01


I am definitely interested to see what the RSL turns out to be; I
think it has many potential benefits. There are also some obvious
issues to be worked out (e.g., mpirun and friends).

As for whether this should go in v1.3, I don't know if it's possible
to say yet -- it will depend on when RSL becomes [at least close to]
ready, what the exact schedule for v1.3 is (which we've been skittish
to define, since we're going for a feature-driven release), etc.

On Aug 16, 2007, at 9:47 PM, Tim Prins wrote:

> WHAT: Solicitation of feedback on the possibility of adding a runtime
> services layer to Open MPI to abstract out the runtime.
>
> WHY: To solidify the interface between OMPI and the runtime
> environment,
> and to allow the use of different runtime systems, including different
> versions of ORTE.
>
> WHERE: Addition of a new framework to OMPI, and changes to many of the
> files in OMPI to funnel all runtime request through this framework.
> Few
> changes should be required in OPAL and ORTE.
>
> WHEN: Development has started in tmp/rsl, but is still in its
> infancy. We hope
> to have a working system in the next month.
>
> TIMEOUT: 8/29/07
>
> ------
> Short version:
>
> I am working on creating an interface between OMPI and the runtime
> system.
> This would make a RSL framework in OMPI which all runtime services
> would be
> accessed from. Attached is a graphic depicting this.
>
> This change would be invasive to the OMPI layer. Few (if any) changes
> will be required of the ORTE and OPAL layers.
>
> At this point I am soliciting feedback as to whether people are
> supportive or not of this change both in general and for v1.3.
>
>
> Long version:
>
> The current model used in Open MPI assumes that one runtime system is
> the best for all environments. However, in many environments it may be
> beneficial to have specialized runtime systems. With our current
> system this
> is not easy to do.
>
> With this in mind, the idea of creating a 'runtime services layer' was
> hatched. This would take the form of a framework within OMPI,
> through which
> all runtime functionality would be accessed. This would allow new or
> different runtime systems to be used with Open MPI. Additionally,
> with such a
> system it would be possible to have multiple versions of open rte
> coexisting,
> which may facilitate development and testing. Finally, this would
> solidify the
> interface between OMPI and the runtime system, as well as provide
> documentation and side effects of each interface function.
>
> However, such a change would be fairly invasive to the OMPI layer, and
> needs a buy-in from everyone for it to be possible.
>
> Here is a summary of the changes required for the RSL (at least how
> it is
> currently envisioned):
>
> 1. Add a framework to ompi for the rsl, and a component to support
> orte.
> 2. Change ompi so that it uses the new interface. This involves:
> a. Moving runtime specific code into the orte rsl component.
> b. Changing the process names in ompi to an opaque object.
> c. change all references to orte in ompi to be to the rsl.
> 3. Change the configuration code so that open-rte is only linked
> where needed.
>
> Of course, all this would happen on a tmp branch.
>
> The design of the rsl is not solidified. I have been playing in a
> tmp branch
> (located at https://svn.open-mpi.org/svn/ompi/tmp/rsl) which
> everyone is
> welcome to look at and comment on, but be advised that things here are
> subject to change (I don't think it even compiles right now). There
> are
> some fairly large open questions on this, including:
>
> 1. How to handle mpirun (that is, when a user types 'mpirun', do they
> always get ORTE, or do they sometimes get a system specific
> runtime). Most
> likely mpirun will always use ORTE, and alternative launching
> programs would
> be used for other runtimes.
> 2. Whether there will be any performance implications. My guess is
> not,
> but am not quite sure of this yet.
>
> Again, I am interested in people's comments on whether they think
> adding
> such abstraction is good or not, and whether it is reasonable to do
> such a
> thing for v1.3.
>
> Thanks,
>
> Tim Prins
> <RSL-Diagram.pdf>
> _______________________________________________
> devel-core mailing list
> devel-core_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel-core

-- 
Jeff Squyres
Cisco Systems