On Aug 24, 2007, at 9:50 AM, Tim Prins wrote:

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.

Right, but that's a side effect. The coordinated checkpoint is not very intrusive, it only requires a limited set of capabilities, which are usually delivered by all RTE. However, if you look just a little bit further, uncoordinated checkpoint (where only one of the processes have to be restarted and join the others in their old "world"), you will notice that the current interface (RSL or PMI) will not support this.


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.

This is again a side effect of the incapacity of the underlying systems of providing the most elementary features we need. But, with ORTE at least we have the potential to overcome these limitations.

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.

We have all the ingredients to make a this RTE layer, i.e. loadable modules. The approach we proposed few months ago, to load a component only when we know it will be needed give us a very slim RTE (once applied everywhere it make sense). The biggest problem I see here is that we will start scattering our efforts on multiple things instead of working together to make what we have right now the best it can be.

  george.


Tim


   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 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-c...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel-core

_______________________________________________
devel-core mailing list
devel-c...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel-core

_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Reply via email to