[Mpi3-tools] Current Version of the MPIR document
Martin Schulz
schulzm at llnl.gov
Wed Jun 16 20:58:09 CDT 2010
Hi Greg,
I (and I think most WG members) agree with you on most, if not all of
the
points. Nobody is happy with the interface as it is and would like to
see
something much better (incl. John from Totalview). However, this is how
things are since they have been organically grown.
In this first step we just wanted to document how the current
interface works,
so that tools that want to code to MPIR or MPI libraries and resource
managers
that want to offer MPIR can do so in a unified way. This will be the
first
reliable document to this effect and that is what Jeff meant with gold
standard.
This is not supposed to be a definition of the latest and greatest for
MPI-3
and hence we also decided to not push for the inclusion into the
standard.
Instead this will only be a side document, but blessed by the forum. I
(and
if I can speak for the rest of the WG members, we) think that this is
essential
in the short term to give tools something to work with and to act as a
starting point for any future interface and improvement.
In the mid/long term (hopefully within MPI-3) we would like to establish
something better than the current MPIR and some of your ideas came up in
the discussions, others make perfectly sense to me and I would like to
see them included. I know that John has some concrete ideas on this
and that there is interest from David at Allinea. Also, both the MPICH
and
the OpenMPI groups have thought about these issues.
Putting these ideas together into a new API draft would be great.
However,
I don't see myself being able to drive another API besides the MPIT API
we are currently working on. If you have the interest and the time to
get
together with the folks and help drive this activity, that would be
great.
The MPI tools WG would certainly be the right forum for this and if it
makes
sense to schedule a or even regular meetings for this, we can certainly
do that. Let me know.
Thanks,
Martin
On Jun 15, 2010, at 5:45 PM, Greg Watson wrote:
> I'll reiterate again my comments/suggestions regarding the tool
> daemon launch extension.
>
> 1. A number of debuggers and tools use the MPI runtime to launch
> their server processes rather than having to implement a second
> parallel launch mechanism. In lieu of standard infrastructure for
> launching tools, it makes sense to use the MPI runtime if possible.
> This approach is currently supported by Open MPI, MPICH2, PE and
> probably others as well.
>
> 2. The current extension relies on reading/writing memory in the
> starter process. This is adequate (although complicated) for
> debuggers, but does not work with other sorts of tools. In order to
> address this, I would like to see these features available from the
> command line as well, and would suggest a requirement that the tool
> daemon variables be able to be specified on the command line of the
> starter process.
>
> 3. The extension provides no control of where or how many server
> processes are launched. I presume the intention is one server
> process per MPI process, but this is not specified, and is probably
> not desirable on shared memory and other types of architectures. At
> a minimum, a "one server process per node" variable is desirable,
> such as "MPIR_one_server_per_node" or something similar. However, it
> may be desirable to make this completely general by allowing the use
> of the same process allocation mechanism provided by the MPI
> implementation.
>
> 4. The extension does not provide any mechanism for server processes
> to identify themselves or the MPI process(es) they are interested
> in. I would suggest a requirement that the each server command line
> or environment be supplied with (a) the MPI rank(s) of the MPI
> process(es) associated with each server; and (b) the PID's of the
> MPI process(es) if launched by the MPI runtime.
>
> 5. Some tools would prefer to start the MPI processes rather than
> attach to existing processes (which implies a ptrace requirement). I
> would suggest the optional variable "MPIR_external_spawn" be
> specified that indicates to the MPI runtime that the processes will
> be spawned externally. For this mode of launch, the identification
> information provided in (3) would be used by the MPI implementation
> to complete the MPI initialization, as well as the by tool. This
> variable would be available only on MPI implementations that support
> this startup mechanism.
>
> As mentioned, a number of MPI implementations already provide most
> of these features, so the burden of adding this support should not
> be great. Providing a standard mechanism for tool daemon launch
> would go a long way to addressing some of the tool infrastructure
> problems that affect most systems today.
>
> The current tool daemon launch extension is clearly targeted at
> TotalView and not designed to be flexible enough for other tools and
> debuggers. If the document goes ahead as-is, it can hardly be said
> to be a "gold standard" for tool writers.
>
> Regards,
> Greg
>
>
> On Jun 14, 2010, at 12:27 PM, Martin Schulz wrote:
>
>> Hi all,
>>
>> Attached is the latest and updated version of the MPIR document,
>> which John
>> DelSignore put together. The intent is still to publish this
>> through the MPI forum
>> as an official document. The details for this are still tbd. and
>> Jeff will lead a
>> discussion on this topic during the forum this week.
>>
>> We don't have a tools WG meeting scheduled for meeting, but if you
>> have
>> any comments or feedback (on the document or how we should publish
>> it),
>> please post it to the list. If necessary or useful, we can also
>> dedicate one
>> of the upcoming tools TelCons for this.
>>
>> Thanks!
>>
>> Martin
>>
>> PS: Feel free to distribute the document further, in particular to
>> tool and
>> MPI developers.
>>
>>
>> <MPIR Process Acquisition Interface 2010-06-11.pdf>
>>
>> ________________________________________________________________________
>> Martin Schulz, schulzm at llnl.gov, http://*people.llnl.gov/schulzm
>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>
>>
>>
>> _______________________________________________
>> Mpi3-tools mailing list
>> Mpi3-tools at lists.mpi-forum.org
>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
>
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20100616/c7f20aab/attachment-0001.html>
More information about the mpiwg-tools
mailing list