February 2015 - mpiwg-ft - mailman3.cels.anl.gov

Re: [mpiwg-ft] call today?
by Jeff Hammond 17 Feb '15

17 Feb '15

You must be running your email server on an exascale computer ;-) Jeff On Tue, Feb 17, 2015 at 12:24 PM, Wesley Bland <wbland(a)anl.gov> wrote: > Hmm…looks like it went out from my personal email on my phone instead of my work email so it probably got silently dropped by the listserv. Sorry about that everybody. > >> On Feb 17, 2015, at 2:22 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> Did you send that email to the list? I do not see on >> http://lists.mpi-forum.org/mpiwg-ft/2015/02/date.php or in any of my >> email folders. >> >> In any case, I'm happy to have the time back. >> >> Happy shoveling - I wore a T-shirt outside all weekend :-) >> >> Jeff >> >> On Tue, Feb 17, 2015 at 12:08 PM, Wesley Bland <wbland(a)anl.gov> wrote: >>> Sorry Jeff. I sent out an announcement about an hour ago. We decided to cancel the call due to my kid’s illness and southern snow/ice. We’ll just do things over email. >>> >>>> On Feb 17, 2015, at 2:06 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> >>>> It's on my calendar but no one is on the bridge. Am I off by a week? >>>> >>>> Thanks, >>>> >>>> Jeff >>>> >>>> -- >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>>> http://jeffhammond.github.io/ >>>> _______________________________________________ >>>> mpiwg-ft mailing list >>>> mpiwg-ft(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >>> >>> _______________________________________________ >>> mpiwg-ft mailing list >>> mpiwg-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-ft] call today?
by Wesley Bland 17 Feb '15

17 Feb '15

Hmm…looks like it went out from my personal email on my phone instead of my work email so it probably got silently dropped by the listserv. Sorry about that everybody. > On Feb 17, 2015, at 2:22 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > Did you send that email to the list? I do not see on > http://lists.mpi-forum.org/mpiwg-ft/2015/02/date.php or in any of my > email folders. > > In any case, I'm happy to have the time back. > > Happy shoveling - I wore a T-shirt outside all weekend :-) > > Jeff > > On Tue, Feb 17, 2015 at 12:08 PM, Wesley Bland <wbland(a)anl.gov> wrote: >> Sorry Jeff. I sent out an announcement about an hour ago. We decided to cancel the call due to my kid’s illness and southern snow/ice. We’ll just do things over email. >> >>> On Feb 17, 2015, at 2:06 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> It's on my calendar but no one is on the bridge. Am I off by a week? >>> >>> Thanks, >>> >>> Jeff >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpiwg-ft mailing list >>> mpiwg-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >> >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] call today?
by Jeff Hammond 17 Feb '15

17 Feb '15

Did you send that email to the list? I do not see on http://lists.mpi-forum.org/mpiwg-ft/2015/02/date.php or in any of my email folders. In any case, I'm happy to have the time back. Happy shoveling - I wore a T-shirt outside all weekend :-) Jeff On Tue, Feb 17, 2015 at 12:08 PM, Wesley Bland <wbland(a)anl.gov> wrote: > Sorry Jeff. I sent out an announcement about an hour ago. We decided to cancel the call due to my kid’s illness and southern snow/ice. We’ll just do things over email. > >> On Feb 17, 2015, at 2:06 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> It's on my calendar but no one is on the bridge. Am I off by a week? >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-ft] call today?
by Wesley Bland 17 Feb '15

17 Feb '15

Sorry Jeff. I sent out an announcement about an hour ago. We decided to cancel the call due to my kid’s illness and southern snow/ice. We’ll just do things over email. > On Feb 17, 2015, at 2:06 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > It's on my calendar but no one is on the bridge. Am I off by a week? > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

call today?
by Jeff Hammond 17 Feb '15

17 Feb '15

It's on my calendar but no one is on the bridge. Am I off by a week? Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-ft] [MPI Forum] #323: User-Level Failure Mitigation
by Jeff Hammond 04 Feb '15

04 Feb '15

So "completion" here (excerpt below) only means "will be globally visible at the first legal opportunity"? I think the text should permit but not require errors to be reported during flush, to accommodate Jim's example. Thanks, Jeff "MPI_WIN_FLUSH completes all outstanding RMA operations initiated by the calling process to the target rank on the specified window. The operations are completed both at the origin and at the target." Sent from my iPhone > On Feb 4, 2015, at 6:35 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > If flush is performed during an exclusive lock epoch, it may not need to wait for remote completion. Keep in mind that flush talks about visibility of updates, not the specific protocol that the implementation needs to use. For example, MPICH implements RMA on top of active messages that traverse ordered channels. In that scenario, flush during an exclusive lock epoch where the lock has already been acquired can be a no-op. If we required win_flush to always wait for remote completion (i.e. always notify) in the FT proposal, we would be prescribing a particular protocol, which we would like to avoid if possible. > >> On Tue, Feb 3, 2015 at 4:14 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> How is win_flush not synchronizing? It cause global visibility of updates. I don't see how a non-synchronizing implementation could exist. >> >> Jeff >> >> Sent from my iPhone >> >> > On Feb 3, 2015, at 12:50 PM, MPI Forum <mpi-forum(a)lists.mpi-forum.org> wrote: >> > >> > #323: User-Level Failure Mitigation >> > -------------------------------------+----------------------------------- >> > Reporter: bosilca | Owner: bosilca >> > Type: Enhancements to standard | Status: new >> > Priority: Scheduled | Milestone: Future >> > Version: MPI 4.0 | Resolution: >> > Keywords: FT | Implementation status: Completed >> > -------------------------------------+----------------------------------- >> > >> > Comment (by bouteill): >> > >> > Replying to [comment:32 jhammond]: >> >> This means that page 5 line 11 of the latest FT proposal must be amended >> > somehow, as it pertains to the use of the phrase "epoch closing" (which >> > should be "epoch-closing", no?), unless you deliberately mean to exclude >> > {{{MPI_WIN_FLUSH(_LOCAL)(_ALL)}}} and {{{MPI_WIN_SYNC}}} from the list of >> > functions that must raise a process failure exception. And if they are >> > excluded, then their relationship to FT is ambiguous, since they are >> > neither communication operations nor epoch-closing synchronization. >> >> >> >> I suppose that we should treat {{{MPI_WIN_FLUSH_LOCAL(_ALL)}}} >> > differently from {{{MPI_WIN_FLUSH(_ALL)}}}, since the former is a local >> > operation and the latter is a nonlocal one. Given that >> > {{{MPI_WIN_FLUSH(_ALL)}}} induce remote completion, they will detect >> > remote process failures and thus can be required to raise these without >> > introducing unreasonable overhead. >> > >> > Ok, thinking more about this I came to the conclusion that the current >> > text is correct: WIN_FLUSH is not local, but it is ordering more than >> > remote completion, so it may not always detect errors. If it does (when >> > the particular implementation does guarantee remote completion), it will >> > raise an exception (as is possible in any cases), when the implementation >> > is not synchronizing, it will not. Mandating the raising of the exception >> > may make it more expensive. >> > >> > We may want to add some rationale/advices to remember why we came to that >> > conclusion (if you agree with me here) ? >> > >> > -- >> > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39> >> > MPI Forum <https://svn.mpi-forum.org/> >> > MPI Forum >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] [MPI Forum] #323: User-Level Failure Mitigation
by Jim Dinan 04 Feb '15

04 Feb '15

If flush is performed during an exclusive lock epoch, it may not need to wait for remote completion. Keep in mind that flush talks about visibility of updates, not the specific protocol that the implementation needs to use. For example, MPICH implements RMA on top of active messages that traverse ordered channels. In that scenario, flush during an exclusive lock epoch where the lock has already been acquired can be a no-op. If we required win_flush to always wait for remote completion (i.e. always notify) in the FT proposal, we would be prescribing a particular protocol, which we would like to avoid if possible. On Tue, Feb 3, 2015 at 4:14 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > How is win_flush not synchronizing? It cause global visibility of updates. > I don't see how a non-synchronizing implementation could exist. > > Jeff > > Sent from my iPhone > > > On Feb 3, 2015, at 12:50 PM, MPI Forum <mpi-forum(a)lists.mpi-forum.org> > wrote: > > > > #323: User-Level Failure Mitigation > > -------------------------------------+----------------------------------- > > Reporter: bosilca | Owner: bosilca > > Type: Enhancements to standard | Status: new > > Priority: Scheduled | Milestone: Future > > Version: MPI 4.0 | Resolution: > > Keywords: FT | Implementation status: Completed > > -------------------------------------+----------------------------------- > > > > Comment (by bouteill): > > > > Replying to [comment:32 jhammond]: > >> This means that page 5 line 11 of the latest FT proposal must be amended > > somehow, as it pertains to the use of the phrase "epoch closing" (which > > should be "epoch-closing", no?), unless you deliberately mean to exclude > > {{{MPI_WIN_FLUSH(_LOCAL)(_ALL)}}} and {{{MPI_WIN_SYNC}}} from the list of > > functions that must raise a process failure exception. And if they are > > excluded, then their relationship to FT is ambiguous, since they are > > neither communication operations nor epoch-closing synchronization. > >> > >> I suppose that we should treat {{{MPI_WIN_FLUSH_LOCAL(_ALL)}}} > > differently from {{{MPI_WIN_FLUSH(_ALL)}}}, since the former is a local > > operation and the latter is a nonlocal one. Given that > > {{{MPI_WIN_FLUSH(_ALL)}}} induce remote completion, they will detect > > remote process failures and thus can be required to raise these without > > introducing unreasonable overhead. > > > > Ok, thinking more about this I came to the conclusion that the current > > text is correct: WIN_FLUSH is not local, but it is ordering more than > > remote completion, so it may not always detect errors. If it does (when > > the particular implementation does guarantee remote completion), it will > > raise an exception (as is possible in any cases), when the implementation > > is not synchronizing, it will not. Mandating the raising of the exception > > may make it more expensive. > > > > We may want to add some rationale/advices to remember why we came to that > > conclusion (if you agree with me here) ? > > > > -- > > Ticket URL: < > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39> > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >

1 0

Re: [mpiwg-ft] [MPI Forum] #323: User-Level Failure Mitigation
by Jeff Hammond 03 Feb '15

03 Feb '15

How is win_flush not synchronizing? It cause global visibility of updates. I don't see how a non-synchronizing implementation could exist. Jeff Sent from my iPhone > On Feb 3, 2015, at 12:50 PM, MPI Forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > #323: User-Level Failure Mitigation > -------------------------------------+----------------------------------- > Reporter: bosilca | Owner: bosilca > Type: Enhancements to standard | Status: new > Priority: Scheduled | Milestone: Future > Version: MPI 4.0 | Resolution: > Keywords: FT | Implementation status: Completed > -------------------------------------+----------------------------------- > > Comment (by bouteill): > > Replying to [comment:32 jhammond]: >> This means that page 5 line 11 of the latest FT proposal must be amended > somehow, as it pertains to the use of the phrase "epoch closing" (which > should be "epoch-closing", no?), unless you deliberately mean to exclude > {{{MPI_WIN_FLUSH(_LOCAL)(_ALL)}}} and {{{MPI_WIN_SYNC}}} from the list of > functions that must raise a process failure exception. And if they are > excluded, then their relationship to FT is ambiguous, since they are > neither communication operations nor epoch-closing synchronization. >> >> I suppose that we should treat {{{MPI_WIN_FLUSH_LOCAL(_ALL)}}} > differently from {{{MPI_WIN_FLUSH(_ALL)}}}, since the former is a local > operation and the latter is a nonlocal one. Given that > {{{MPI_WIN_FLUSH(_ALL)}}} induce remote completion, they will detect > remote process failures and thus can be required to raise these without > introducing unreasonable overhead. > > Ok, thinking more about this I came to the conclusion that the current > text is correct: WIN_FLUSH is not local, but it is ordering more than > remote completion, so it may not always detect errors. If it does (when > the particular implementation does guarantee remote completion), it will > raise an exception (as is possible in any cases), when the implementation > is not synchronizing, it will not. Mandating the raising of the exception > may make it more expensive. > > We may want to add some rationale/advices to remember why we came to that > conclusion (if you agree with me here) ? > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323#comment:39> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum

1 0

Re: [mpiwg-ft] Today's Con Call
by Wesley Bland 03 Feb '15

03 Feb '15

The notes from today's call are on the wiki now: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ftwg2015-02-03 On Tue, Feb 3, 2015 at 12:47 PM, Aurélien Bouteiller <bouteill(a)icl.utk.edu> wrote: > I would like to add to the agenda the early findings regarding memory > safety on K. > > Aurelien > > -- > ~~~ Aurélien Bouteiller, Ph.D. ~~~ > ~ Research Scientist @ ICL ~ > The University of Tennessee, Innovative Computing Laboratory > 1122 Volunteer Blvd, suite 309, Knoxville, TN 37996 > tel: +1 (865) 974-9375 fax: +1 (865) 974-8296 > https://icl.cs.utk.edu/~bouteill/ > > > > > Le 3 févr. 2015 à 12:01, Wesley Bland <wbland(a)anl.gov> a écrit : > > As a reminder, we have our usual con call today at 3:00 EST. > > We’ll be discussing: > > - Ticket #472 (Clarify behavior of multiple error handlers in a single > call) > - Ticket #324 (Clarify MPI_ERRORS_ARE_FATAL scope of abort) > - Ticket #323 (ULFM) > - WG and/or plenary time at Portland Meeting > > Dial-in information: > Phone: 712-432-0360 > Code: 623998# > > Thanks, > Wesley > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > >

1 0

Re: [mpiwg-ft] Today's Con Call
by Aurélien Bouteiller 03 Feb '15

03 Feb '15

I would like to add to the agenda the early findings regarding memory safety on K. Aurelien -- ~~~ Aurélien Bouteiller, Ph.D. ~~~ ~ Research Scientist @ ICL ~ The University of Tennessee, Innovative Computing Laboratory 1122 Volunteer Blvd, suite 309, Knoxville, TN 37996 tel: +1 (865) 974-9375 fax: +1 (865) 974-8296 https://icl.cs.utk.edu/~bouteill/ > Le 3 févr. 2015 à 12:01, Wesley Bland <wbland(a)anl.gov> a écrit : > > As a reminder, we have our usual con call today at 3:00 EST. > > We’ll be discussing: > > - Ticket #472 (Clarify behavior of multiple error handlers in a single call) > - Ticket #324 (Clarify MPI_ERRORS_ARE_FATAL scope of abort) > - Ticket #323 (ULFM) > - WG and/or plenary time at Portland Meeting > > Dial-in information: > Phone: 712-432-0360 <tel:712-432-0360> > Code: 623998# > > Thanks, > Wesley > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0