February 2012 - mpiwg-tools - mailman3.cels.anl.gov

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by David Lecomber 13 Feb '12

13 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Another issue I see with the current definition is where the DLL > name variables live, which is currently defined to live in the MPI > process itself. I was wondering is there was any benefit to > allowing (but not requiring) the DLL name variables to live in the > MPI starter, rather than the MPI processes. Most implementations > currently put MPIR_dll_name[] in the MPI process, but that may > require the debugger to read the variable from each MPI process, > which creates scalability issues if the debugger wants to load the > DLL at a single point in its front-end process. I'd be interested > to hear if other feel this is an issue. Hi John, I'd say it's much of a much-ness really. I'd be happy with supporting that. Allowing the variable to live in the starter is fine - and if it's not there, or not constant in the system, then it would equally be fine in the MPI processes. To scale reading the message queues, you'd already have to have made reading a single variable (ie. the dll name) scale so I don't think scalability of that variable itself is a concern. Regarding the location and reading of the DLL itself, that is a potential concern, ie. is it read in from a global file system at the nodes, or pushed down a tree? Making that scale is something the debugger can do in a way that's appropriate for the system in hand - if need be. Cheers David - -- David Lecomber CTO, Allinea Software Ltd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85Qi8ACgkQHl7D0k2ADlsvTACdGhoBnlyGeS4WGvMuAZPEa7sr MWMAn0lidvjc35iU4itp8qyXg08gPBKX =T3tT -----END PGP SIGNATURE-----

1 0

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by Martin Schulz 13 Feb '12

13 Feb '12

Hi Jeff, all, Independent from the technical discussion, I think you both are right regarding the original proposal. We basically put this aside when we starting diving into MPIR and when we decided to pull MPIR out of a proposal for the standard and into a separate document. We should probably do the latter also for the other debugging proposals if they use a similar (non MPI API) interface. The question is, though, should these all be separate documents or do you want to add to the MPIR document and keep all these interfaces together? Martin PS: Do you want a TelCon to talk about these issues? Our next usual slot would be next Monday. On Feb 13, 2012, at 8:45 AM, Jeff Squyres wrote: > On Feb 13, 2012, at 11:26 AM, John DelSignore wrote: > >> The new scheme seems to do a reasonable job at separating out 32-bit vs 64-bit libraries, but it has no provisions for cross or heterogeneous debugging. When the debugger is loading a MQD DLL for a target process, it want to find a library that can be validly loaded into the debugger's address space and is appropriate for the target process. It says. "For example, a tool can attempt to dynamically load each of the files in the array; the file that loads successfully is likely a good candidate to be used by the tool." It's the "likely a good candidate" part that makes me concerned. >> >> If we take the LANL Roadrunner machine as an extreme example, the debugger might be targeting a mixture of Linux-x86_64 and Linux-Cell processes, call this the "target platform" for a given target process. Also, various debugger processes may be running on Linux-x86_64 and Linux-Cell, call this the "debugger platform" for a given debugger process. Note that it is not necessarily the case that the "target platform" is the same as "debugger platform" when the MQD DLL is loaded. >> >> To cover the cross or heterogeneous debugging cases, I think the debugger needs to search the list of DLLs looking for one that is appropriate for both the "debugger platform" and the "target platform". The current proposal allows the debugger to find one that is appropriate for the "debugger platform", but it may not be the right DLL for the "target platform". Perhaps we need a way to be more explicit about the debugger and target platforms for each entry in the vector. Do we care about solving this problem? > > I think I was intentionally fuzzy in this text to let the tool decide what is best. > > The text in that paragraph is couched in language like "For example, ...". Did you want to make it softer? > >> Another issue I see with the current definition is where the DLL name variables live, which is currently defined to live in the MPI process itself. I was wondering is there was any benefit to allowing (but not requiring) the DLL name variables to live in the MPI starter, rather than the MPI processes. Most implementations currently put MPIR_dll_name[] in the MPI process, but that may require the debugger to read the variable from each MPI process, which creates scalability issues if the debugger wants to load the DLL at a single point in its front-end process. I'd be interested to hear if other feel this is an issue. > > Mmm. Good point. > > The PDF I sent earlier was talking about the general technique of an argv-style array. I think the intent was to specifically list a) the variable name, and b) the location of that variable in the sections about each DLL (e.g., in the MPIR document, and in the MQD DLL verbiage that hasn't been written yet). > > However, there is a sentence in the PDF I sent that should probably be changed: > > ----- > However, the tool that wishes to make use of these interfaces typically only has knowledge of the MPI process itself ï¿½ it may not know where the supplemental tool interface implementations can be found. > ----- > > Should probably be changed to: > > ----- > However, the tool that wishes to make use of these interfaces typically only has knowledge of ***an MPI "starter" process, or the set of MPI processes*** itself ï¿½ it may not know where the supplemental tool interface implementations can be found. > ----- > > ...and then adjust the rest of the text where we state "The MPI process..." > > Howzat? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by Jeff Squyres 13 Feb '12

13 Feb '12

On Feb 13, 2012, at 11:26 AM, John DelSignore wrote: > The new scheme seems to do a reasonable job at separating out 32-bit vs 64-bit libraries, but it has no provisions for cross or heterogeneous debugging. When the debugger is loading a MQD DLL for a target process, it want to find a library that can be validly loaded into the debugger's address space and is appropriate for the target process. It says. "For example, a tool can attempt to dynamically load each of the files in the array; the file that loads successfully is likely a good candidate to be used by the tool." It's the "likely a good candidate" part that makes me concerned. > > If we take the LANL Roadrunner machine as an extreme example, the debugger might be targeting a mixture of Linux-x86_64 and Linux-Cell processes, call this the "target platform" for a given target process. Also, various debugger processes may be running on Linux-x86_64 and Linux-Cell, call this the "debugger platform" for a given debugger process. Note that it is not necessarily the case that the "target platform" is the same as "debugger platform" when the MQD DLL is loaded. > > To cover the cross or heterogeneous debugging cases, I think the debugger needs to search the list of DLLs looking for one that is appropriate for both the "debugger platform" and the "target platform". The current proposal allows the debugger to find one that is appropriate for the "debugger platform", but it may not be the right DLL for the "target platform". Perhaps we need a way to be more explicit about the debugger and target platforms for each entry in the vector. Do we care about solving this problem? I think I was intentionally fuzzy in this text to let the tool decide what is best. The text in that paragraph is couched in language like "For example, ...". Did you want to make it softer? > Another issue I see with the current definition is where the DLL name variables live, which is currently defined to live in the MPI process itself. I was wondering is there was any benefit to allowing (but not requiring) the DLL name variables to live in the MPI starter, rather than the MPI processes. Most implementations currently put MPIR_dll_name[] in the MPI process, but that may require the debugger to read the variable from each MPI process, which creates scalability issues if the debugger wants to load the DLL at a single point in its front-end process. I'd be interested to hear if other feel this is an issue. Mmm. Good point. The PDF I sent earlier was talking about the general technique of an argv-style array. I think the intent was to specifically list a) the variable name, and b) the location of that variable in the sections about each DLL (e.g., in the MPIR document, and in the MQD DLL verbiage that hasn't been written yet). However, there is a sentence in the PDF I sent that should probably be changed: ----- However, the tool that wishes to make use of these interfaces typically only has knowledge of the MPI process itself ï¿½ it may not know where the supplemental tool interface implementations can be found. ----- Should probably be changed to: ----- However, the tool that wishes to make use of these interfaces typically only has knowledge of ***an MPI "starter" process, or the set of MPI processes*** itself ï¿½ it may not know where the supplemental tool interface implementations can be found. ----- ...and then adjust the rest of the text where we state "The MPI process..." Howzat? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by John DelSignore 13 Feb '12

13 Feb '12

Hi Jeff, Jeff Squyres wrote: > I would like to revive the following old proposal: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/dllapi Seems like a worthy activity. > Digging a little in SVN, I found text supporting this proposal -- see > section 1.5., "Locating Tool Interface Symbols", in the attached PDF > (it was part of a larger "tools" chapter). > > Does anyone remember the state that we left this proposal in? > > 1. The proposal, as it reads, looks fine to me. But that's likely > because I wrote it. :-) I don't remember if there was any substantive > WG/Forum feedback on this proposal. Do you? I don't think we ever gave it the scrutiny it needs, and I think it's pretty close, though I do have a few concerns I outline below. > 2. Or did we let it go because we concentrated on the MPIR document > first, and wanted to get that done before advancing this one? I think we did want to focus on the MPIR Process Acquisition Interface document and the MPIT document first, so message queue display and dll finding took a backseat. > 3. ...? IIRC, I originally included the description of MPIR_dll_name[] in the MPIR Process Acquisition Interface document, but it was removed because strictly speaking the variable is not needed by MPI process acquisition, it is needed by MPI message queue display (MQD). At one point a year or two ago I had volunteered to write up the message queue display too, but I never found time to do that, so as far as I know MPIR_dll_name[] and the MQD interface are not "officially" described anywhere yet. Here are my concerns with the current proposal... The new scheme seems to do a reasonable job at separating out 32-bit vs 64-bit libraries, but it has no provisions for cross or heterogeneous debugging. When the debugger is loading a MQD DLL for a target process, it want to find a library that can be validly loaded into the debugger's address space and is appropriate for the target process. It says. "For example, a tool can attempt to dynamically load each of the files in the array; the file that loads successfully is likely a good candidate to be used by the tool." It's the "likely a good candidate" part that makes me concerned. If we take the LANL Roadrunner machine as an extreme example, the debugger might be targeting a mixture of Linux-x86_64 and Linux-Cell processes, call this the "target platform" for a given target process. Also, various debugger processes may be running on Linux-x86_64 and Linux-Cell, call this the "debugger platform" for a given debugger process. Note that it is not necessarily the case that the "target platform" is the same as "debugger platform" when the MQD DLL is loaded. To cover the cross or heterogeneous debugging cases, I think the debugger needs to search the list of DLLs looking for one that is appropriate for both the "debugger platform" and the "target platform". The current proposal allows the debugger to find one that is appropriate for the "debugger platform", but it may not be the right DLL for the "target platform". Perhaps we need a way to be more explicit about the debugger and target platforms for each entry in the vector. Do we care about solving this problem? Another issue I see with the current definition is where the DLL name variables live, which is currently defined to live in the MPI process itself. I was wondering is there was any benefit to allowing (but not requiring) the DLL name variables to live in the MPI starter, rather than the MPI processes. Most implementations currently put MPIR_dll_name[] in the MPI process, but that may require the debugger to read the variable from each MPI process, which creates scalability issues if the debugger wants to load the DLL at a single point in its front-end process. I'd be interested to hear if other feel this is an issue. Cheers, John D.

1 0

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by Jeff Squyres 13 Feb '12

13 Feb '12

On Feb 13, 2012, at 9:59 AM, David Lecomber wrote: > I don't remember where the proposal got - but we did implement support > for this in DDT - although the variable exists, it appears to be set > to null in my current OMPI install. Looks like there's a bug in it. I fixed it in our hg repo for handle debugging (fair warning to the rest of the WG: we're going to revive that proposal, too... :-) ). Let me know if that works for you. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-tools] Reviving old proposal: finding tools DLLs
by David Lecomber 13 Feb '12

13 Feb '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/02/12 14:51, Jeff Squyres wrote: > I would like to revive the following old proposal: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/dllapi > > Digging a little in SVN, I found text supporting this proposal -- > see section 1.5., "Locating Tool Interface Symbols", in the > attached PDF (it was part of a larger "tools" chapter). > > Does anyone remember the state that we left this proposal in? > > 1. The proposal, as it reads, looks fine to me. But that's likely > because I wrote it. :-) I don't remember if there was any > substantive WG/Forum feedback on this proposal. Do you? > > 2. Or did we let it go because we concentrated on the MPIR document > first, and wanted to get that done before advancing this one? > > 3. ...? Hi Jeff, I don't remember where the proposal got - but we did implement support for this in DDT - although the variable exists, it appears to be set to null in my current OMPI install. Best wishes David - -- David Lecomber CTO, Allinea Software Ltd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85JUkACgkQHl7D0k2ADluM8ACgkogb3u7eWCn7mFHFaQ0QVZ09 OkIAoIvHy4ipLmW+g2IpUCJeGzbLwYV4 =r/7u -----END PGP SIGNATURE-----

1 0

[Mpi3-tools] Reviving old proposal: finding tools DLLs
by Jeff Squyres 13 Feb '12

13 Feb '12

I would like to revive the following old proposal: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/dllapi Digging a little in SVN, I found text supporting this proposal -- see section 1.5., "Locating Tool Interface Symbols", in the attached PDF (it was part of a larger "tools" chapter). Does anyone remember the state that we left this proposal in? 1. The proposal, as it reads, looks fine to me. But that's likely because I wrote it. :-) I don't remember if there was any substantive WG/Forum feedback on this proposal. Do you? 2. Or did we let it go because we concentrated on the MPIR document first, and wanted to get that done before advancing this one? 3. ...? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0