On 8/9/2010 11:19 AM, John DelSignore wrote:

Dong H. Ahn wrote:

...

Hi John,

I just looked at the revision and I think this addressed most of the issues I've raised except for the MPIR_attach_fifo support. Sorry, I forgot about MPIR_attach_fifo. I had to scrounge around in my email to find the description. Here's what I have, from an email you sent on 7/9/10:

============================================= ... I would also hope to cover a recently implemented MPIR extension on OpenRTE/OpenMPI: MPIR_attach_fifo support.

-------

" char MPIR_attach_fifo[256];

Definition is not required.

Definition is contained within the address space of the starter process.

Variable is written by the tool, and read by the starter process. MPIR_attach_fifo is a null-terminated character string that is written by the tool into the address space of the starter process. The string is the path name of a FIFO (named pipe). Writing a byte into this FIFO will cause the starter process to start to monitor MPIR_being_debugged in attach mode. " -------

As part of LaunchMON/STAT OpenRTE/OpenMPI port, Ralph Castain reproduced BlueGene's MPIR colocation extension but there was a performance requirement of orterun that kept orterun from polling on the value changes of MPIR_being_debugged for attach case by default. So we addressed it by making orterun open up a FIFO and its comm thread block on the FIFO along with other TCP channels; when a debugger attaches to orterun and writes a byte into it, the starter process looks at MPIR_being_debugger and performs the co-location service. =============================================

...

If it is missing from this revision because of a lack of technical details, Ralph and I should be able to provide them. Given that I know zilch MPIR_attach_fifo, it would make sense for someone else (not me) to write-up the description and incorporate it into the document. Since it is an extension, I think it should be added in sections 7 and 9. Sections 7.3 and 9.19 seem appropriate places for the additions.

Ralph and I will try to draft it before the next call. I think Ralph is more qualified to provide answers below but here is my version.

Finally, I'd like a little clarification on this extension...

1) Who creates and owns the FIFO? Is it the starter process?

Yes.

On what node is the FIFO created? My concern is this: If the starter process is being debugged remotely (e.g.: totalview -r remotehost mpiexec) does the debugger have to open the FIFO on the remotehost? I'd assume so, which means that the debugger has to extend its remote debugging protocol to execute this "write to FIFO" operation. This wasn't an issue with STAT/LaunchMON because this tool co-locates the launchmon engine to the starter process which knows how to deal with files. BTW, is "write-to-file" not supported for TotalView remote debugging protocol?

2) Who is responsible for deleting the FIFO? What happens if the debugger forcibly kills the starter process? Is the FIFO leaked?

The starter process is responsible for deleting it. As to your second question, I think this kind of cleanup requirement applies not only to this FIFO but also all other resources that the RM holds. The RM should be able to release all of its resources when its starter process is forcibly killed by the controlling debugger. In any case, I was told that oretrun creates a per-session directory where it put all of the file resources, which was also used for managing this FIFO resource. I suspect that orterun can perform the FIFO clean-up in the same fashion it cleans up other files in this directory when forcibly killed by the debugger.

3) Why didn't you use a socket or a signal instead of a FIFO? With a socket or signal, you don't have lifetime issues. With a signal, you don't have remote debugging issues.

We thought about those options but none are well-suited for orterun. Most signals are already taken for this resource manager; a socket could be used, but then one will have to worry about authentication and etc... Best, Dong

Cheers, John D.

...

Best, Dong

On 8/6/2010 11:58 AM, John DelSignore wrote:

...

Hi,

Attached is the most recent draft (8/6/2010) of the MPIR document for discussion during the 8/9 meeting.

I updated it to reflect the comments I received in email on the 6/11/2010 draft that I felt warranted changing the document.

I also copy and pasted Jeff's mpimsgq_dll_locations description from the Latex file and the MPI website; this is intended as a placeholder until someone (not me) has time to cleanup the text to fit into the document.

The "Diffs" document shows the changes relative to the 6/11/2010 draft.

Cheers, John D.

Jeff Squyres wrote:

...

On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote:

...

Here is the proposed schedule for the upcoming meetings after tomorrow:

8/9 - Final discussion of the MPIR document 8/23 - Discussion of the completed/integrated MPIT document 9/6 - Labor day - no meeting 9/16-9/18 - MPI forum meeting in Stuttgart First reading of the MPIR document 9/20 - Feedback from the MPI forum, MPIT discussions Webex links for these meetings are now up on the wiki.

---

Mpi3-tools mailing list [email protected] http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

_______________________________________________ Mpi3-tools mailing list [email protected] http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools