
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Greg,</div><div><br></div><div>I (and I think most WG members) agree with you on most, if not all of the</div><div>points. Nobody is happy with the interface as it is and would like to see</div><div>something much better (incl. John from Totalview). However, this is how</div><div>things are since they have been organically grown.</div><div><br></div><div>In this first step we just wanted to document how the current interface works,</div><div>so that tools that want to code to MPIR or MPI libraries and resource managers</div><div>that want to offer MPIR can do so in a unified way. This will be the first</div><div>reliable document to this effect and that is what Jeff meant with gold standard.</div><div><br></div><div>This is not supposed to be a definition of the latest and greatest for MPI-3</div><div>and hence we also decided to not push for the inclusion into the standard.</div><div>Instead this will only be a side document, but blessed by the forum. I (and</div><div>if I can speak for the rest of the WG members, we) think that this is essential</div><div>in the short term to give tools something to work with and to act as a</div><div>starting point for any future interface and improvement.</div><div><br></div><div>In the mid/long term (hopefully within MPI-3) we would like to establish</div><div>something better than the current MPIR and some of your ideas came up in</div><div>the discussions, others make perfectly sense to me and I would like to</div><div>see them included. I know that John has some concrete ideas on this</div><div>and that there is interest from David at Allinea. Also, both the MPICH and</div><div>the OpenMPI groups have thought about these issues. </div><div><br></div><div>Putting these ideas together into a new API draft would be great. However,</div><div>I don't see myself being able to drive another API besides the MPIT API</div><div>we are currently working on. If you have the interest and the time to get</div><div>together with the folks and help drive this activity, that would be great.</div><div>The MPI tools WG would certainly be the right forum for this and if it makes</div><div>sense to schedule a or even regular meetings for this, we can certainly</div><div>do that. Let me know.</div><div><br></div><div>Thanks,</div><div><br></div><div>Martin</div><div><br></div><div><br></div><br><div><div>On Jun 15, 2010, at 5:45 PM, Greg Watson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I'll reiterate again my comments/suggestions regarding the tool daemon launch extension.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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. <br><br>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.<div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Greg</div><div><br></div><div><br><div><div>On Jun 14, 2010, at 12:27 PM, Martin Schulz wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi all,</div><div><br></div><div>Attached is the latest and updated version of the MPIR document, which John</div><div>DelSignore put together. The intent is still to publish this through the MPI forum</div><div>as an official document. The details for this are still tbd. and Jeff will lead a</div><div>discussion on this topic during the forum this week.</div><div><br></div><div>We don't have a tools WG meeting scheduled for meeting, but if you have </div><div>any comments or feedback (on the document or how we should publish it), </div><div>please post it to the list. If necessary or useful, we can also dedicate one</div><div>of the upcoming tools TelCons for this.</div><div><br></div><div>Thanks!</div><div><br></div><div>Martin</div><div><br></div><div>PS: Feel free to distribute the document further, in particular to tool and</div><div>MPI developers.</div><div><br></div><div><font class="Apple-style-span"><br></font></div></div></div><span><MPIR Process Acquisition Interface 2010-06-11.pdf></span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></div></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________________________________________</div><div>Martin Schulz, <a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>, <a href="http://*people.llnl.gov/schulzm">http://*people.llnl.gov/schulzm</a></div><div>CASC @ Lawrence Livermore National Laboratory, Livermore, USA</div><div><br></div></div></div></span><br class="Apple-interchange-newline"> </div><br></div>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br>http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools<br></blockquote></div><br></div></div>_______________________________________________<br>Mpi3-tools mailing list<br><a href="mailto:Mpi3-tools@lists.mpi-forum.org">Mpi3-tools@lists.mpi-forum.org</a><br>http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools<br></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>________________________________________________________________________</div><div>Martin Schulz, schulzm@llnl.gov, <a href="http://people.llnl.gov/schulzm">http://people.llnl.gov/schulzm</a></div><div>CASC @ Lawrence Livermore National Laboratory, Livermore, USA</div><div><br></div></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>