March 2012 - mpiwg-ft - mailman3.cels.anl.gov

[Mpi3-ft] Clarification Ticket 323: MPI_ANY_SOURCE and MPI_Test(any)
by Josh Hursey 16 Mar '12

16 Mar '12

I believe my reasoning is correct below, but thought I would ask the group to confirm. Consider the following code snippet: --------------------- MPI_Irecv(..., MPI_ANY_SOURCE, ..., &req); /* Some other process in the communicator fails */ MPI_Test(&req, &flag, &status); --------------------- The proposal in #323 says that the request should be marked as MPI_ERR_PENDING and not complete. So what should the value of 'flag' and 'status' be when returning from MPI_Test? According to the standard, 'flag = true' indicates two things: 1) the operation is completed 2) The 'status' object is set For the MPI_ANY_SOURCE case above, the operation is -not- completed, so (1) is violated; therefore I think MPI_Test should set 'flag' equal to 'false'. However, is the 'status' also not set? Should MPI_Test return MPI_SUCCESS or MPI_ERR_PENDING? If MPI_Test is to return MPI_ERR_PENDING directly, then there is no needed to inspect 'status'. However if we replace MPI_Test with MPI_Testany(1, &req, &index, &flag, &status) then the operation would return MPI_ERR_IN_STATUS, and the user must inspect the 'status' field for the true error value. So we would still set 'flag = false', but would also need to set the 'status'. That is if we want MPI_Test* return an error code that indicates that the request as 'failed, but not completed'. According to the standard, if no operation is completed then MPI_Testany "returns flag = false, returns a value of MPI_UNDEFINED in index and status is undefined." So according to the MPI_Testany logic, in this case 'flag = false', 'status is undefined', and the operation should return MPI_SUCCESS. Is that the expected behavior for the code snippet above? I think so, but I thought I would double check with the group. This means that the user can only 'see' the MPI_ERR_PENDING state of the request when they call an MPI_Wait* operation, which might not be what they would normally want to do (because they do not want to block). -- Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] Fault Tolerance Query Interface
by TERRY DONTJE 16 Mar '12

16 Mar '12

I vote for the attribute option. --td On 3/14/2012 11:44 AM, Darius Buntinas wrote: > I vote for the attribute option. I don't know what using the MPI_T interface would add, but I guess we could do both. I don't like the explicit query function. > > -d > > > On Mar 14, 2012, at 9:19 AM, Josh Hursey wrote: > >> During the MPI Forum meeting it was requested that the FT WG add the >> ability to query the implementation to determine if it supports the >> functionality described in the new proposal. Such a query interface >> would allow the user to determine whether they should use a code path >> including fault recovery techniques, or use an alternative path that >> does not include such error checking. >> >> Note that both execution paths must be supported by the MPI >> implementation, but if the implementation will never return the error >> codes defined in that chapter (and makes 'MPI_Comm_shrink' a >> 'MPI_Comm_dup' and 'MPI_Comm_invalidate' a noop) then the user is >> doing extra work that is not necessary for that implementation. >> Further, if the implementation does not support the functionality, >> this would provide the user with an early sanity check and allow them >> to bail out before wasting time on the machine. >> >> At bottom are a few suggestions for how to provide this functionality. >> This would be a ticket targeted at 3.1. It is not necessary >> functionality for the current set of tickets (e.g., 323), just a user >> convenience interface. >> >> The MPI Predefined Attribute option sounds the best to me, though the >> MPI_T interface extension is interesting as well. What do others >> think? >> >> -- Josh >> >> >> MPI Defined Attribute: >> ---------------------- >> Section 8.1.2 of the MPI 2.2 standard defined a small set of >> attributes that are defined for MPI_COMM_WORLD to "describe the >> execution environment." We could add a new attribute: >> - MPI_SUPPORT_PROC_FAILURE : Boolean variable that indicates whether >> the implementation is able to provide support for the behavior >> specified in Chapter 17. >> >> The MPI implementation would have to define this 'key' so users can >> portably query it. The 'value' should be set to 'true' if the >> functionality is support, and all other values indicate that the >> implementation does not support the functionality. >> >> >> Explicit MPI Function(s): >> ------------------------- >> MPI_FT_QUERY(bool&supported); >> A general query interface to determine if the functionality in Chapter >> 17 is supported. >> >> We could also explore a per-communication object interface to allow >> for future implementation flexibility (though it would be more >> difficult for the user to program against). >> MPI_COMM_FT_QUERY(MPI_Comm comm, bool&supported); >> MPI_WIN_FT_QUERY(...); >> MPI_FILE_FT_QUERY(...); >> >> We could also have an an initialization function, similar to threads: >> MPI_INIT_FT(required, provided); >> >> >> MPI_T interface: >> ---------------- >> Extend the interface, as appropriate and in coordination with the >> tools group, to allow the user to query the implementation to >> determine support for various error codes. This would possibly allow >> us to extend beyond the error codes defined in Chapter 17. >> >> So that users can query for 'how well supported is MPI_ERR_X' or 'what >> is the state of the implementation after returning MPI_ERR_X'. For >> example, returning MPI_ERR_ARG is not critical in most implementation >> configurations (but in some it may be). So this would allow the user >> to ask the MPI implementation if it can continue using MPI after an >> error, or what it can do after the error is returned. >> >> This thread might also be interesting to consider for this point: >> http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft -- Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle *- Performance Technologies* 95 Network Drive, Burlington, MA 01803 Email terry.dontje(a)oracle.com <mailto:[email protected]>

1 0

Re: [Mpi3-ft] Fault Tolerance Query Interface
by Darius Buntinas 14 Mar '12

14 Mar '12

I vote for the attribute option. I don't know what using the MPI_T interface would add, but I guess we could do both. I don't like the explicit query function. -d On Mar 14, 2012, at 9:19 AM, Josh Hursey wrote: > During the MPI Forum meeting it was requested that the FT WG add the > ability to query the implementation to determine if it supports the > functionality described in the new proposal. Such a query interface > would allow the user to determine whether they should use a code path > including fault recovery techniques, or use an alternative path that > does not include such error checking. > > Note that both execution paths must be supported by the MPI > implementation, but if the implementation will never return the error > codes defined in that chapter (and makes 'MPI_Comm_shrink' a > 'MPI_Comm_dup' and 'MPI_Comm_invalidate' a noop) then the user is > doing extra work that is not necessary for that implementation. > Further, if the implementation does not support the functionality, > this would provide the user with an early sanity check and allow them > to bail out before wasting time on the machine. > > At bottom are a few suggestions for how to provide this functionality. > This would be a ticket targeted at 3.1. It is not necessary > functionality for the current set of tickets (e.g., 323), just a user > convenience interface. > > The MPI Predefined Attribute option sounds the best to me, though the > MPI_T interface extension is interesting as well. What do others > think? > > -- Josh > > > MPI Defined Attribute: > ---------------------- > Section 8.1.2 of the MPI 2.2 standard defined a small set of > attributes that are defined for MPI_COMM_WORLD to "describe the > execution environment." We could add a new attribute: > - MPI_SUPPORT_PROC_FAILURE : Boolean variable that indicates whether > the implementation is able to provide support for the behavior > specified in Chapter 17. > > The MPI implementation would have to define this 'key' so users can > portably query it. The 'value' should be set to 'true' if the > functionality is support, and all other values indicate that the > implementation does not support the functionality. > > > Explicit MPI Function(s): > ------------------------- > MPI_FT_QUERY(bool &supported); > A general query interface to determine if the functionality in Chapter > 17 is supported. > > We could also explore a per-communication object interface to allow > for future implementation flexibility (though it would be more > difficult for the user to program against). > MPI_COMM_FT_QUERY(MPI_Comm comm, bool &supported); > MPI_WIN_FT_QUERY(...); > MPI_FILE_FT_QUERY(...); > > We could also have an an initialization function, similar to threads: > MPI_INIT_FT(required, provided); > > > MPI_T interface: > ---------------- > Extend the interface, as appropriate and in coordination with the > tools group, to allow the user to query the implementation to > determine support for various error codes. This would possibly allow > us to extend beyond the error codes defined in Chapter 17. > > So that users can query for 'how well supported is MPI_ERR_X' or 'what > is the state of the implementation after returning MPI_ERR_X'. For > example, returning MPI_ERR_ARG is not critical in most implementation > configurations (but in some it may be). So this would allow the user > to ask the MPI implementation if it can continue using MPI after an > error, or what it can do after the error is returned. > > This thread might also be interesting to consider for this point: > http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

[Mpi3-ft] Fault Tolerance Query Interface
by Josh Hursey 14 Mar '12

14 Mar '12

During the MPI Forum meeting it was requested that the FT WG add the ability to query the implementation to determine if it supports the functionality described in the new proposal. Such a query interface would allow the user to determine whether they should use a code path including fault recovery techniques, or use an alternative path that does not include such error checking. Note that both execution paths must be supported by the MPI implementation, but if the implementation will never return the error codes defined in that chapter (and makes 'MPI_Comm_shrink' a 'MPI_Comm_dup' and 'MPI_Comm_invalidate' a noop) then the user is doing extra work that is not necessary for that implementation. Further, if theï¿½implementationï¿½does not support the functionality, this would provide the user with an early sanity check and allow them to bail out before wasting time on the machine. At bottom are a few suggestions for how to provide this functionality. This would be a ticket targeted at 3.1. It is not necessary functionality for the current set of tickets (e.g., 323), just a user convenience interface. The MPI Predefined Attribute option sounds the best to me, though the MPI_T interface extension is interesting as well. What do others think? -- Josh MPI Defined Attribute: ---------------------- Section 8.1.2 of the MPI 2.2 standard defined a small set of attributes that are defined for MPI_COMM_WORLD to "describe the execution environment." We could add a new attribute: ï¿½- MPI_SUPPORT_PROC_FAILURE : Boolean variable that indicates whether the implementation is able to provide support for the behavior specified in Chapter 17. The MPI implementation would have to define this 'key' so users can portably query it. The 'value' should be set to 'true' if the functionality is support, and all other values indicate that the implementation does not support the functionality. Explicit MPI Function(s): ------------------------- MPI_FT_QUERY(bool &supported); A general query interface to determine if the functionality in Chapter 17 is supported. We could also explore a per-communication object interface to allow for future implementation flexibility (though it would be more difficult for the user to program against). MPI_COMM_FT_QUERY(MPI_Comm comm, bool &supported); MPI_WIN_FT_QUERY(...); MPI_FILE_FT_QUERY(...); We could also have an an initialization function, similar to threads: MPI_INIT_FT(required, provided); MPI_T interface: ---------------- Extend the interface, as appropriate and in coordination with the tools group, to allow the user to query the implementation to determine support for various error codes. This would possibly allow us to extend beyond the error codes defined in Chapter 17. So that users can query for 'how well supported is MPI_ERR_X' or 'what is the state of the implementation after returning MPI_ERR_X'. For example, returning MPI_ERR_ARG is not critical in most implementation configurations (but in some it may be). So this would allow the user to ask the MPI implementation if it can continue using MPI after an error, or what it can do after the error is returned. This thread might also be interesting to consider for this point: ï¿½ http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

[Mpi3-ft] FT WG Teleconference Wednesday @ Noon EST
by Josh Hursey 13 Mar '12

13 Mar '12

Reminder that we have a teleconf Wednesday at Noon EST. Date: March 14, 2012 Time: Noon EST/New York Dial-in information: 877-801-8130 Code: 1044056 Agenda: - Misc. - MPI Forum debrief - Meeting next week? - User-Level Failure Mitigation Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323 - Next Steps - New name for 'invalidate' http://lists.mpi-forum.org/mpi3-ft/2012/03/1080.php - RMA sub-ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/325 - I/O sub-ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/326 - Dynamics sub-ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/327 - FT Query Interface (from the forum, but the link below is related) http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php - Other items? Additional Agenda Items [as time permits]: - FA-MPI Alternative Proposal (Tony) http://lists.mpi-forum.org/mpi3-ft/2012/02/1048.php - Piggybacking (Martin S.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Piggybacking - Run-Through Stabilization Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/rts_proposal_main https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/alt_simplified_rts_pro… http://lists.mpi-forum.org/mpi3-ft/2012/01/0959.php - Process Recovery (Josh H.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/process_recovery_2 - MPI Forum notes discussion (?) http://lists.mpi-forum.org/mpi3-ft/2012/01/0983.php http://lists.mpi-forum.org/mpi3-ft/2011/07/0805.php - Error to Fault changes proposal (Darius B.) http://lists.mpi-forum.org/mpi3-ft/2011/06/0773.php - Network Channel Failure http://lists.mpi-forum.org/mpi3-ft/2011/06/0730.php - FT Query Interface http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php Next Meetings: * March 14, 2012 (Teleconf) * March 21, 2012 (Teleconf - If needed) * March 28, 2012 (Teleconf) * April 4, 2012 (Teleconf - If needed) * April 11, 2012 (Teleconf) * April 18, 2012 (Teleconf - If needed) * May 2, 2012 (Teleconf) * May 9, 2012 (Teleconf - If needed) * May 16, 2012 (Teleconf) * May 23, 2012 (Teleconf - If needed) * May 28, 2012 (MPI Forum Meeting) Respond to the list if you have any additional topics that you would like to discuss. -- Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] Invalidate by any other name
by Aurélien Bouteiller 12 Mar '12

12 Mar '12

I like revoke too Aurelien Le 12 mars 2012 à 17:22, Thomas Herault a écrit : > revoke +1 > > Thomas > > Le 12 mars 2012 à 12:41, Darius Buntinas a écrit : > >> terminate >> retire >> abate >> >> -d >> >> >> On Mar 12, 2012, at 11:34 AM, Darius Buntinas wrote: >> >>> disable? >>> >>> >>> -d >>> >>> On Mar 12, 2012, at 9:52 AM, Josh Hursey wrote: >>> >>>> One of the lingering syntax issues from the MPI Forum meeting last week has to do with the MPI_*_invalidate() operation. >>>> >>>> "Invalid communicator" has a well defined meaning in the MPI standard, so it is bad to have an alternative meeting for the FT functionally. Therefore, we need a new name for this 'invalidate' operation. >>>> >>>> Below are some suggestions (thanks to Jeff Squyres and Thomas Herault for some of these): >>>> >>>> suspend >>>> annul >>>> negate >>>> discredit >>>> disqualify >>>> neutralize >>>> quash >>>> revoke >>>> rescind >>>> repeal >>>> revoke >>>> nuke >>>> nix >>>> explode >>>> smite >>>> infirmo >>>> >>>> Are there others that folks want to suggest? >>>> >>>> I kind of like 'repeal' or 'revoke' since we are revoking the context associated with the communication object through this function. >>>> >>>> -- Josh >>>> >>>> >>>> -- >>>> Joshua Hursey >>>> Postdoctoral Research Associate >>>> Oak Ridge National Laboratory >>>> http://users.nccs.gov/~jjhursey >>>> _______________________________________________ >>>> mpi3-ft mailing list >>>> mpi3-ft(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >>> >> >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft -- * Dr. Aurélien Bouteiller * Researcher at Innovative Computing Laboratory * University of Tennessee * 1122 Volunteer Boulevard, suite 350 * Knoxville, TN 37996 * 865 974 6321

1 0

Re: [Mpi3-ft] Invalidate by any other name
by Thomas Herault 12 Mar '12

12 Mar '12

revoke +1 Thomas Le 12 mars 2012 ï¿½ 12:41, Darius Buntinas a ï¿½crit : > terminate > retire > abate > > -d > > > On Mar 12, 2012, at 11:34 AM, Darius Buntinas wrote: > >> disable? >> >> >> -d >> >> On Mar 12, 2012, at 9:52 AM, Josh Hursey wrote: >> >>> One of the lingering syntax issues from the MPI Forum meeting last week has to do with the MPI_*_invalidate() operation. >>> >>> "Invalid communicator" has a well defined meaning in the MPI standard, so it is bad to have an alternative meeting for the FT functionally. Therefore, we need a new name for this 'invalidate' operation. >>> >>> Below are some suggestions (thanks to Jeff Squyres and Thomas Herault for some of these): >>> >>> suspend >>> annul >>> negate >>> discredit >>> disqualify >>> neutralize >>> quash >>> revoke >>> rescind >>> repeal >>> revoke >>> nuke >>> nix >>> explode >>> smite >>> infirmo >>> >>> Are there others that folks want to suggest? >>> >>> I kind of like 'repeal' or 'revoke' since we are revoking the context associated with the communication object through this function. >>> >>> -- Josh >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> _______________________________________________ >>> mpi3-ft mailing list >>> mpi3-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] Invalidate by any other name
by Darius Buntinas 12 Mar '12

12 Mar '12

terminate retire abate -d On Mar 12, 2012, at 11:34 AM, Darius Buntinas wrote: > disable? > > > -d > > On Mar 12, 2012, at 9:52 AM, Josh Hursey wrote: > >> One of the lingering syntax issues from the MPI Forum meeting last week has to do with the MPI_*_invalidate() operation. >> >> "Invalid communicator" has a well defined meaning in the MPI standard, so it is bad to have an alternative meeting for the FT functionally. Therefore, we need a new name for this 'invalidate' operation. >> >> Below are some suggestions (thanks to Jeff Squyres and Thomas Herault for some of these): >> >> suspend >> annul >> negate >> discredit >> disqualify >> neutralize >> quash >> revoke >> rescind >> repeal >> revoke >> nuke >> nix >> explode >> smite >> infirmo >> >> Are there others that folks want to suggest? >> >> I kind of like 'repeal' or 'revoke' since we are revoking the context associated with the communication object through this function. >> >> -- Josh >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >

1 0

Re: [Mpi3-ft] Invalidate by any other name
by Sur, Sayantan 12 Mar '12

12 Mar '12

Disable +1 === Sayantan Sur, Ph.D. Intel Corp. > -----Original Message----- > From: mpi3-ft-bounces(a)lists.mpi-forum.org [mailto:mpi3-ft- > bounces(a)lists.mpi-forum.org] On Behalf Of Darius Buntinas > Sent: Monday, March 12, 2012 9:35 AM > To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group > Subject: Re: [Mpi3-ft] Invalidate by any other name > > disable? > > > -d > > On Mar 12, 2012, at 9:52 AM, Josh Hursey wrote: > > > One of the lingering syntax issues from the MPI Forum meeting last week > has to do with the MPI_*_invalidate() operation. > > > > "Invalid communicator" has a well defined meaning in the MPI standard, so > it is bad to have an alternative meeting for the FT functionally. Therefore, we > need a new name for this 'invalidate' operation. > > > > Below are some suggestions (thanks to Jeff Squyres and Thomas Herault > for some of these): > > > > suspend > > annul > > negate > > discredit > > disqualify > > neutralize > > quash > > revoke > > rescind > > repeal > > revoke > > nuke > > nix > > explode > > smite > > infirmo > > > > Are there others that folks want to suggest? > > > > I kind of like 'repeal' or 'revoke' since we are revoking the context > associated with the communication object through this function. > > > > -- Josh > > > > > > -- > > Joshua Hursey > > Postdoctoral Research Associate > > Oak Ridge National Laboratory > > http://users.nccs.gov/~jjhursey > > _______________________________________________ > > mpi3-ft mailing list > > mpi3-ft(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] Invalidate by any other name
by Darius Buntinas 12 Mar '12

12 Mar '12

disable? -d On Mar 12, 2012, at 9:52 AM, Josh Hursey wrote: > One of the lingering syntax issues from the MPI Forum meeting last week has to do with the MPI_*_invalidate() operation. > > "Invalid communicator" has a well defined meaning in the MPI standard, so it is bad to have an alternative meeting for the FT functionally. Therefore, we need a new name for this 'invalidate' operation. > > Below are some suggestions (thanks to Jeff Squyres and Thomas Herault for some of these): > > suspend > annul > negate > discredit > disqualify > neutralize > quash > revoke > rescind > repeal > revoke > nuke > nix > explode > smite > infirmo > > Are there others that folks want to suggest? > > I kind of like 'repeal' or 'revoke' since we are revoking the context associated with the communication object through this function. > > -- Josh > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0