August 2011 - mpiwg-tools - mailman3.cels.anl.gov

[Mpi3-tools] Signal safety comments in the MPI tool information interface proposal
by Martin Schulz 27 Aug '11

27 Aug '11

Hi Brian, (I am also cc-ing the MPI-3 tools group) At the last forum you had some concerns about the text passage in the MPI_T proposal regarding signal safety. We have rewritten the text - what do you think about the advice to implementors below? Does this address your concerns? Thanks, Martin Sampling based tools rely on the ability to call the MPI tool information interface, in particular routines to start, stop, read, write and reset performance variables, from any program context, including asynchronous contexts such as signal handlers. MPI implementations should strive, if possible in their particular environment, to enable these usage scenarios for all or a subset of the routines mentioned above. If implementing only a subset, the read, write, and reset routines are typically the most critical for sampling based tools. An MPI implementation should clearly document any restrictions on the program contexts in which the MPI tool information interface can be used. Restrictions might include guaranteeing usage outside of all signals or outside a specific set of signals. Any restrictions could be documented, for example, through the description returned by \mpifunc{MPI\_T\_PVAR\_GET\_INFO}. ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Changes to the MPI_T*_ document
by Martin Schulz 27 Aug '11

27 Aug '11

Hi all, I created a new version of the MPI_T document based on the feedback from the MPI forum plus some additional comments. The new draft is at: https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Tools/mpit… Please take a look at it and see if any more changes are necessary. To meet the two week rule, we have until 9/8 to post the document to the MPI forum. I don't think we need another tools TelCon until then (but please speak up if you think we do or if there are any other topics to cover), but I still would like feedback on the questions that I sent around in the last email - so far I have only heard from Bronis; additional feedback would be helpful. A) Naming: MPI_T or a different name? ============================== I have changed all names to be MPI_T_<lowercase>, but I have not made any further name changes. Bronis's vote was for keeping just the "T" and that would be the easiest and least disruptive to both the document and the existing prototype(s). Does anybody have a good idea or a strong opinion about this? B) Types: which types to support? ========================== The new document has the following list: MPI_INT MPI_UNSIGNED MPI_UNSIGNED_LONG MPI_UNSIGNED_LONG_LONG MPI_COUNT MPI_CHAR MPI_DOUBLE With the following rationale included in the text: The \MPI/ tool information interface relies mainly on unsigned datatypes for integer values since most variables are expected to represent counters or resource sizes. \const{MPI\_INT} is provided for additional flexibility and is expected to be used mainly for control variables. Providing all basic datatypes, in particular providing all signed and unsigned variants of integer types, would lead to a larger number of types, which tools need to interpret. This would cause unnecessary complexity in the implementation of tools based on the \MPI/ tool information interface. C) Signal safety ============= I liked Bronis's version of the text and included it in the document. I'll also start a separate email with Brian to get his feedback. If there are any other pending issues with this document, please let me know. I really hope we can make the next first reading the last reading, but for this it would be extremely helpful if more people would look over the document! Thanks! Martin On Aug 17, 2011, at 4:37 PM, Bronis R. de Supinski wrote: > > Martin: > > Re: >> - Naming: People didn't like MPI_T_ and wanted something >> more expressive. MPI_Tool_ would be the obvious choice >> and that would be fine with me. Does anyone have a better >> suggestion? We can't spend more than four characters on >> it, though, or we will run into problems with the max. name >> size (even after shortening some names). Also, I would like >> this to be the final name change :). > > I still feel that MPI_T is the best choice. No matter > what prefix you choose, someone will not like it. > > [snip] > >> - We had some lengthy discussion on the thread and async >> signal safety. Below is a suggestion for a rewrite - once I get >> some feedback from our group, I will forward this to Brian, >> since he had the most issues with the current wording. >> >> \begin{implementors} >> Sampling based tools rely on the ability to call the MPI >> tool information interface, in particular routines to start, stop, >> read, write and reset performance variables, from any program >> context, including asynchronous contexts such as signal handlers. >> MPI implementations should strive, if possible in their particular > > OK through the above. > >> environment, to enable this behavior for all or a subset of the > > Which "behavior"? You do not define any behavior above. You > define support for usage scenarios. Change to: > > environment, to enable these usage scenarios for all or a subset of the > >> routines mentioned above. If implementing only a subset, the >> read, write, and reset routines are typically the most critical > >> for sampling based tools. If an MPI implementation >> is not able to provide such a behavior or if the behavior is only >> guaranteed under certain circumstances (e.g., for certain signals), >> this should be clearly documented, e.g., through the description >> return by {\mpifunc MPI\_T\_Get\_info}. > > "such a"? UGH! Poor antecedent for "this". "return by"? Huh? > > change to: > > for sampling based tools. An MPI implementation should clearly > document any restrictions on the program contexts in which > the MPI tool information interface can be used. Restrictions > might include guaranteeing usage outside of all signals or > outside a specific set of signals. Any restrictions could be > documented, for example, through the description returned by > {\mpifunc MPI\_T\_Get\_info}. > >> \end{implementors} > > Bronis > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Changes to the MPI_T*_ document
by Bronis R. de Supinski 17 Aug '11

17 Aug '11

Martin: Re: > - Naming: People didn't like MPI_T_ and wanted something > more expressive. MPI_Tool_ would be the obvious choice > and that would be fine with me. Does anyone have a better > suggestion? We can't spend more than four characters on > it, though, or we will run into problems with the max. name > size (even after shortening some names). Also, I would like > this to be the final name change :). I still feel that MPI_T is the best choice. No matter what prefix you choose, someone will not like it. [snip] > - We had some lengthy discussion on the thread and async > signal safety. Below is a suggestion for a rewrite - once I get > some feedback from our group, I will forward this to Brian, > since he had the most issues with the current wording. > > \begin{implementors} > Sampling based tools rely on the ability to call the MPI > tool information interface, in particular routines to start, stop, > read, write and reset performance variables, from any program > context, including asynchronous contexts such as signal handlers. > MPI implementations should strive, if possible in their particular OK through the above. > environment, to enable this behavior for all or a subset of the Which "behavior"? You do not define any behavior above. You define support for usage scenarios. Change to: environment, to enable these usage scenarios for all or a subset of the > routines mentioned above. If implementing only a subset, the > read, write, and reset routines are typically the most critical > for sampling based tools. If an MPI implementation > is not able to provide such a behavior or if the behavior is only > guaranteed under certain circumstances (e.g., for certain signals), > this should be clearly documented, e.g., through the description > return by {\mpifunc MPI\_T\_Get\_info}. "such a"? UGH! Poor antecedent for "this". "return by"? Huh? change to: for sampling based tools. An MPI implementation should clearly document any restrictions on the program contexts in which the MPI tool information interface can be used. Restrictions might include guaranteeing usage outside of all signals or outside a specific set of signals. Any restrictions could be documented, for example, through the description returned by {\mpifunc MPI\_T\_Get\_info}. > \end{implementors} Bronis

1 0

[Mpi3-tools] Changes to the MPI_T*_ document
by Martin Schulz 17 Aug '11

17 Aug '11

Hi all, Sorry for being quiet on this topic over the last few weeks, I was overwhelmed with other stuff. I started editing the MPI Tool Information Interface document and will send out a new version for review soon. Before that, I wanted to bring up three issues that were raised during the last reading that require a bit more discussion: - Naming: People didn't like MPI_T_ and wanted something more expressive. MPI_Tool_ would be the obvious choice and that would be fine with me. Does anyone have a better suggestion? We can't spend more than four characters on it, though, or we will run into problems with the max. name size (even after shortening some names). Also, I would like this to be the final name change :). - Use of unsigned datatypes in the list of MPI datatypes MPI_T can use: the argument was that counters and resource sizes should always be 0 or more. This would make the list of approved types (also, people requested LONG to be added) MPI_UNSIGNED_INT MPI_UNSIGNED_LONG MPI_UNSIGNED_LONG_LONG MPI_DOUBLE MPI_CHAR MPI_COUNT Does this sound good? Do we need the signed version for some/all of these as well? It would be good to keep the list small, though, since tools will have to have long switch statements with a case for every type. - We had some lengthy discussion on the thread and async signal safety. Below is a suggestion for a rewrite - once I get some feedback from our group, I will forward this to Brian, since he had the most issues with the current wording. \begin{implementors} Sampling based tools rely on the ability to call the MPI tool information interface, in particular routines to start, stop, read, write and reset performance variables, from any program context, including asynchronous contexts such as signal handlers. MPI implementations should strive, if possible in their particular environment, to enable this behavior for all or a subset of the routines mentioned above. If implementing only a subset, the read, write, and reset routines are typically the most critical for sampling based tools. If an MPI implementation is not able to provide such a behavior or if the behavior is only guaranteed under certain circumstances (e.g., for certain signals), this should be clearly documented, e.g., through the description return by {\mpifunc MPI\_T\_Get\_info}. \end{implementors} Please let me know if you have any comments on the issues above. Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0