Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Tim Prins (tprins_at_[hidden])
Date: 2007-08-24 09:50:03

George Bosilca wrote:
> Looks like I'm the only one barely excited about this idea. The
> system that you described, is well known. It been around for around
> 10 years, and it's called PMI. The interface you have in the tmp
> branch as well as the description you gave in your email are more
> than similar with what they sketch in the following two documents:
Yes, I am well acquainted with these documents, and the PMI did provide
a lot of inspiration for the RSL.

> Now, there is something wrong with reinventing the wheel if there are
> no improvements. And so far I'm unable to notice any major
> improvement neither compared with PMI nor with what we have today
> (except maybe being able to use PMI inside Open MPI).
This is true. The RSL is designed to handle exactly what we need right
now. This does not mean that the interface cannot be extended later. The
current RSL is a starting point.

> Again, my main concern is about fault tolerance. There is nothing in
> PMI (and nothing in RSL so far) that allow any kind of fault
> tolerance [And believe me re-writing the MPICH mpirun to allow
> checkpoint/restart is a hassle].
I am open to any extensions that are needed. Again, the current version
is designed as a starting point. Also, I have been talking a lot with
Josh and the current RSL is more than enough to support
checkpoint/restart as currently implemented. I would be interested in
talking about any additions that are needed.

> Moreover, your approach seems to
> open the possibility of having heterogeneous RTE (in terms of
> features) which in my view is definitively the wrong approach.
Do you mean having different RTEs that support different features?
Personally I do not see this as a horrible thing. In fact, we already
deal with this problem, since different systems support different
things. For instance, we support comm_spawn on most systems, but not all.

I do not understand why a user should have to use a RTE which supports
every system ever imagined, and provides every possible fault-tolerant
feature, when all they want is a thin RTE.


> george.
> 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 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]
> _______________________________________________
> devel-core mailing list
> devel-core_at_[hidden]