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

[Mpi3-rma] Withdraw ticket #283
by Jim Dinan 27 Feb '12

27 Feb '12

Hi All, Given how busy we will be at the next meeting, I think that we should withdraw ticket #283 (clarification of C-types for MPI window attribute get/set routines): https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 Instead of following the full ticket procedure, I think we should handle this within the chapter committee. This is a clarification to the existing text that does not change any semantics. If anyone is opposed, please speak up. If I don't hear anything by Thursday, I'll assume we have consensus to handle this at the chapter level. Best, ~Jim.

1 0

Re: [Mpi3-rma] Fault Tolerance & RMA Discussion
by George Bosilca 22 Feb '12

22 Feb '12

Based on the discussion and opinions expressed during this call, the new FT proposal has been amended to include RMA operations. The FT model for windows is similar to the point-to-point mode: break nothing by default, provide tools to the user level to break and fix the issues. Thus, on group based operations only ranks directly involved in RMA operations with failed processes will be notified. A special function (MPI_Win_invalidate) is available to mark the window as improper to RMA operations, other wise (and this with few restrictions) further RMA not including the failed processes should proceed as expected in a failure-free execution. The current version if the FT proposal is attached to this email, and can be accessed in the working group wiki @ https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/User_Level_Failure_Mitiga…. We expect to have a final version of the proposal by Monday noon EST, as requested by the MPI_Forum to be able to have a first reading at the next meeting. We are looking forward to your comments. george. On Feb 7, 2012, at 16:57 , Josh Hursey wrote: > Attached are my notes from the RMA meeting this morning. > > Thanks, > Josh > > > On Mon, Feb 6, 2012 at 2:45 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We are going to meet from 10-11 am (Eastern) on Feb. 7 to continue our conversation. We will use the same call-in information as before. > > Thanks, > Josh > > > On Thu, Feb 2, 2012 at 3:00 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We made some really good progress on today's call. Attached are some notes that I took from the call. > > At the end of the call there were a couple of items that we wanted to get a finer understanding of. As a result we are going to try to setup another teleconf. > > Below is a doodle poll to pick a date/time: > http://www.doodle.com/kzmiknie8yz4wxkc > > If you are interested in attending this teleconf, please fill out the poll by 2 pm Eastern on Monday, Feb. 6. > > Thanks, > Josh > > > On Thu, Feb 2, 2012 at 10:01 AM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > Just a reminder that we are meeting today at Noon Eastern to discuss RMA in the context of the fault tolerance proposal. > > The Run-Through Stabilization proposal can be found attached to the ticket: > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… > > We will be focusing on section 17.11 of that document. Note that this section does not currently explicitly account for the new RMA proposal, but we would like to remedy that for the next reading. > > Thanks, > Josh > > On Wed, Jan 25, 2012 at 3:15 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > There was no one date/time that worked for everyone, but I chose a time that worked for most of the respondents. We will meet Thursday, Feb. 2 from 12-1 pm EST/New York to discuss this topic. > > We can use the following teleconf information: > US Toll Free number: 877-801-8130 > Toll number: 1-203-692-8690 > Access Code: 1044056 > > Thanks, > Josh > > > On Mon, Jan 23, 2012 at 4:33 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > (Cross posted to both the RMA and FT MPI-3 listservs) > > During the FT plenary session at the Jan. MPI Forum meeting it was recommended that some of the members of the FT group and the RMA group have a meeting to hash out the precise details of the FT semantics for the RMA chapter. So I would like to facilitate such a discussion, preferability in the next week (so we have time to fine tune things before the next forum meeting). > > In general, we are trying to answer the question "How should RMA operations behave when a process failure occurs?" The feeling seemed to be that the current approach is ok (invalidating the window, forcing recreation/validation), but the statement that the memory exposed in the window is 'undefined' seemed excessive. The suggestion was to change the wording to something like "Only the memory associated with a window that was targeted by an operation that modified it is undefined after process failure in the group associated with the window." This lead to a considerable amount of debate in the meeting, so it was suggested that we take the discussion offline. > > Below is a link to a doodle poll to find a good time for a teleconf. If you are interested in participating in this discussion, please fill this poll out by 2 PM Eastern on Wed. Jan 25 so we can set the date/time. > http://www.doodle.com/vd33va5h8iankega > > Thanks, > Josh > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > <RMA-FT-Teleconf-02-07-2012.txt>_______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] [Mpi3-hybridpm] Fwd: MPI shared memory allocation issues
by Dave Goodell 13 Feb '12

13 Feb '12

I'm not sure what happened here. I didn't re-send this. So a mail server or maybe the listserv must have re-sent this for some bizarre reason. -Dave On Mar 28, 2011, at 1:28 PM CDT, Dave Goodell wrote: > Forwarding this mail to a broader audience, based on our discussion here at the March 2011 MPI Forum meeting. There was additional correspondence on this thread that I can forward as needed, but this forwarded mail contains my core argument against the original (allocate+free+fence) proposal. > > -Dave > > Begin forwarded message: > >> From: Dave Goodell <goodell(a)mcs.anl.gov> >> Date: February 24, 2011 11:18:20 AM CST >> To: Ron Brightwell <rbbrigh(a)sandia.gov>, Douglas Miller <dougmill(a)us.ibm.com>, "Bronis R. de Supinski" <bronis(a)llnl.gov>, Jim Dinan <dinan(a)mcs.anl.gov>, Pavan Balaji <balaji(a)mcs.anl.gov>, Marc Snir <snir(a)illinois.edu> >> Subject: MPI shared memory allocation issues >> >> I voiced concerns at the last MPI forum meeting about the proposed MPI extensions for allocating shared memory. In particular I was concerned about "MPI_Shm_fence". Pavan asked me to write up a quick email to this group in order to help clarify my view in the discussion; this is that email. Please widen the distribution list as appropriate, I just mailed the addresses that Pavan indicated to me. FYI, I am not currently subscribed to the mpi3-hybrid list. >> >> First, I view multithreaded programming within an OS process and multiprocess programming using a shared memory region to be essentially the same problem. There are probably alternative interpretations of the words "process" and "thread" that could muddy the picture here, but for the sake of clarity, let's use the conventional meanings for the moment. Also, I am not interested in discussing distributed shared memory (DSM) here, I think that bringing it up just confuses the discussion further. My primary objections to the proposal are valid entirely within a discussion of conventional shared memory, processes, and threads. >> >> Given that preface, I believe that many, if not all, of the issues raised by Boehm's paper, "Threads Cannot Be Implemented As a Library" [1], apply here. In particular, some variation on the example from section 4.3 is probably an issue, but the others seem to apply as well. The performance example is also relevant here, but in an even more dramatic fashion given the dearth of synchronization primitives offered by the proposal. >> >> I do not believe that we can specify a way to program the provided shared memory in any way that is robust and useful to the user, because C and Fortran do not give us enough of a specification in order to do so. Without getting into the business of compiler writing, MPI has no way to give the user any meaningful guarantees. Just as Boehm noted about pthreads, we can probably come up with an approach that will work most of the time. But that's a pretty flimsy guarantee for a standard like MPI. >> >> If you ignore the difficulty in specifying an interface that can actually be used correctly, then another issue arises. The only proposed synchronization mechanism virtually guarantees that the user can at best utilize the allocated shared memory region to share data that is written once and otherwise read-only. Any other shared memory programming techniques are either going to be non-portable (e.g., using pthread mutexes or calls/macros from some atomic operations library), or they will be limited to potentially slow dark-ages techniques such as Dekker's Algorithm with excessive MPI_Shm_fence-ing. So does this proposal really empower the user in any meaningful way? >> >> I don't see a compelling advantage to putting this into MPI as opposed to providing this as some third-party library on top of MPI. Sure, it's easy to implement the allocate/free calls inside of MPI because the machinery is typically there. But a third-party library would be able to escape some of the extremely generic portability constraints of the MPI standard and would therefore be able to provide a more robust interface to the user. A discussion of DSM might make putting it into MPI more compelling because access to the network hardware might be involved, but I'm not particularly interested in having that discussion right now. I think that MPI-3 RMA would probably be more suitable for that use case. >> >> -Dave >> >> [1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf >> > > > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm

1 0

Re: [Mpi3-rma] [Mpi3-hybridpm] Fwd: MPI shared memory allocation issues
by Torsten Hoefler 12 Feb '12

12 Feb '12

Dave, On Mon, Mar 28, 2011 at 01:28:48PM -0500, Dave Goodell wrote: > Forwarding this mail to a broader audience, based on our discussion > here at the March 2011 MPI Forum meeting. There was additional > correspondence on this thread that I can forward as needed, but this > forwarded mail contains my core argument against the original > (allocate+free+fence) proposal. Thanks! This is an important discussion. Let me recap below what we discussed in the RMA group when moving towards the newer integrated allocate_shared. > Begin forwarded message: > > > From: Dave Goodell <goodell(a)mcs.anl.gov> > > Date: February 24, 2011 11:18:20 AM CST > > To: Ron Brightwell <rbbrigh(a)sandia.gov>, Douglas Miller <dougmill(a)us.ibm.com>, "Bronis R. de Supinski" <bronis(a)llnl.gov>, Jim Dinan <dinan(a)mcs.anl.gov>, Pavan Balaji <balaji(a)mcs.anl.gov>, Marc Snir <snir(a)illinois.edu> > > Subject: MPI shared memory allocation issues > > > > I voiced concerns at the last MPI forum meeting about the proposed > > MPI extensions for allocating shared memory. In particular I was > > concerned about "MPI_Shm_fence". Pavan asked me to write up a quick > > email to this group in order to help clarify my view in the > > discussion; this is that email. Please widen the distribution list > > as appropriate, I just mailed the addresses that Pavan indicated to > > me. FYI, I am not currently subscribed to the mpi3-hybrid list. > > > > First, I view multithreaded programming within an OS process and > > multiprocess programming using a shared memory region to be > > essentially the same problem. There are probably alternative > > interpretations of the words "process" and "thread" that could muddy > > the picture here, but for the sake of clarity, let's use the > > conventional meanings for the moment. Also, I am not interested in > > discussing distributed shared memory (DSM) here, I think that > > bringing it up just confuses the discussion further. My primary > > objections to the proposal are valid entirely within a discussion of > > conventional shared memory, processes, and threads. > > > > Given that preface, I believe that many, if not all, of the issues > > raised by Boehm's paper, "Threads Cannot Be Implemented As a > > Library" [1], apply here. In particular, some variation on the > > example from section 4.3 is probably an issue, but the others seem > > to apply as well. The performance example is also relevant here, > > but in an even more dramatic fashion given the dearth of > > synchronization primitives offered by the proposal. > > > > I do not believe that we can specify a way to program the provided > > shared memory in any way that is robust and useful to the user, > > because C and Fortran do not give us enough of a specification in > > order to do so. Without getting into the business of compiler > > writing, MPI has no way to give the user any meaningful guarantees. > > Just as Boehm noted about pthreads, we can probably come up with an > > approach that will work most of the time. But that's a pretty > > flimsy guarantee for a standard like MPI. Yes, as Boehm points out, serial compiler optimizations can have very bad effects on concurrently running code accessing close-by memory. However, as you point out, the situation is equivalent to what we have today in pthreads and the proposal does not claim any more, it says "The consistency of load/store accesses from/to the shared memory as observed by the user program depends on the architecture.". We can extend it to include the compiler and maybe reference Boehm's paper (I would see this as a ticket 0 change). I agree to the general sentiment that it is impossible to implement shared memory semantics in a language that doesn't even have a real memory model. However, at the same time, I want to remind us that the behavior of Fortran was *never* 100% correct in MPI <= 2.2 (and we rely in this TR for MPI-3.0). At the same time, Fortran/MPI programs are ubiquitous :-). But let's discuss Boehm's identified correctness issues here: * 4.1 Concurrent modification This is only an issue if users rely on the consistency of the underlying hardware, if they use Win_flush and friends (as advised), such a reordering would be illegal. One downside is that this will only work in C and Fortran will probably may have all kinds of wacky problems with code movement as usual (however, they should be in a position to fix this with the new bindings and the Fortran TR). * 4.2 Rewriting of Adjacent Data This applies to the unified window as well where we simply specify the byte granularity of updates (an architecture could work with larger chunks (e.g., words) and cause the same trouble). So this issue is not limited to the shared memory window, especially when fast remote memory access hardware is used. Here we face the general trade-off between fast hardware access and safety (securing it through a software layer). We decided that byte-consistency is something we can expect from vendors. Also, the vendor library is always free to return MPI_ERR_RMA_SHARED (like he can always choose to not offer the unified memory model). * 4.3 Register Promotion While this is certainly a problem with threads, it would not be one with MPI windows because they have to dereference the address of the accessed memory and would thus prevent register promotion. Copying the data into a faster memory region would also not harm because the remote side has to query the addresses anyway. Again, restrictions may apply for Fortran codes. > > If you ignore the difficulty in specifying an interface that can > > actually be used correctly, then another issue arises. The only > > proposed synchronization mechanism virtually guarantees that the > > user can at best utilize the allocated shared memory region to share > > data that is written once and otherwise read-only. Any other shared > > memory programming techniques are either going to be non-portable > > (e.g., using pthread mutexes or calls/macros from some atomic > > operations library), or they will be limited to potentially slow > > dark-ages techniques such as Dekker's Algorithm with excessive > > MPI_Shm_fence-ing. So does this proposal really empower the user in > > any meaningful way? I agree. This should be addressed by the merge into the RMA context which offers all required functionality (we avoided memory locks on purpose because they are evil). > > I don't see a compelling advantage to putting this into MPI as > > opposed to providing this as some third-party library on top of MPI. > > Sure, it's easy to implement the allocate/free calls inside of MPI > > because the machinery is typically there. But a third-party library > > would be able to escape some of the extremely generic portability > > constraints of the MPI standard and would therefore be able to > > provide a more robust interface to the user. A discussion of DSM > > might make putting it into MPI more compelling because access to the > > network hardware might be involved, but I'm not particularly > > interested in having that discussion right now. I think that MPI-3 > > RMA would probably be more suitable for that use case. First, I am against DSM. Second, I believe that it may be very valuable to have this kind of functionality in MPI because virtually all large-scale codes have to become hybrid. The main issue are the associated memory saving (on-node communication with MPI is often sufficiently fast). I believe the current practice of mixing OpenMP and MPI to achieve this simple goal may be suboptimal (OpenMP supports only the "shared everything" (threaded) model and enables thus a whole new class of bugs and races). All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] Fault Tolerance & RMA Discussion
by Josh Hursey 07 Feb '12

07 Feb '12

Attached are my notes from the RMA meeting this morning. Thanks, Josh On Mon, Feb 6, 2012 at 2:45 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We are going to meet from 10-11 am (Eastern) on Feb. 7 to continue our > conversation. We will use the same call-in information as before. > > Thanks, > Josh > > > On Thu, Feb 2, 2012 at 3:00 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > >> We made some really good progress on today's call. Attached are some >> notes that I took from the call. >> >> At the end of the call there were a couple of items that we wanted to get >> a finer understanding of. As a result we are going to try to setup another >> teleconf. >> >> Below is a doodle poll to pick a date/time: >> http://www.doodle.com/kzmiknie8yz4wxkc >> >> If you are interested in attending this teleconf, please fill out the >> poll by 2 pm Eastern on Monday, Feb. 6. >> >> Thanks, >> Josh >> >> >> On Thu, Feb 2, 2012 at 10:01 AM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >> >>> Just a reminder that we are meeting today at Noon Eastern to discuss RMA >>> in the context of the fault tolerance proposal. >>> >>> The Run-Through Stabilization proposal can be found attached to the >>> ticket: >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… >>> >>> We will be focusing on section 17.11 of that document. Note that this >>> section does not currently explicitly account for the new RMA proposal, but >>> we would like to remedy that for the next reading. >>> >>> Thanks, >>> Josh >>> >>> On Wed, Jan 25, 2012 at 3:15 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >>> >>>> There was no one date/time that worked for everyone, but I chose a time >>>> that worked for most of the respondents. We will meet Thursday, Feb. 2 from >>>> 12-1 pm EST/New York to discuss this topic. >>>> >>>> We can use the following teleconf information: >>>> US Toll Free number: 877-801-8130 >>>> Toll number: 1-203-692-8690 >>>> Access Code: 1044056 >>>> >>>> Thanks, >>>> Josh >>>> >>>> >>>> On Mon, Jan 23, 2012 at 4:33 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >>>> >>>>> (Cross posted to both the RMA and FT MPI-3 listservs) >>>>> >>>>> During the FT plenary session at the Jan. MPI Forum meeting it was >>>>> recommended that some of the members of the FT group and the RMA group have >>>>> a meeting to hash out the precise details of the FT semantics for the RMA >>>>> chapter. So I would like to facilitate such a discussion, preferability in >>>>> the next week (so we have time to fine tune things before the next forum >>>>> meeting). >>>>> >>>>> In general, we are trying to answer the question "How should RMA >>>>> operations behave when a process failure occurs?" The feeling seemed to be >>>>> that the current approach is ok (invalidating the window, forcing >>>>> recreation/validation), but the statement that the memory exposed in the >>>>> window is 'undefined' seemed excessive. The suggestion was to change the >>>>> wording to something like "Only the memory associated with a window that >>>>> was targeted by an operation that modified it is undefined after process >>>>> failure in the group associated with the window." This lead to a >>>>> considerable amount of debate in the meeting, so it was suggested that we >>>>> take the discussion offline. >>>>> >>>>> Below is a link to a doodle poll to find a good time for a teleconf. >>>>> If you are interested in participating in this discussion, please fill this >>>>> poll out by 2 PM Eastern on Wed. Jan 25 so we can set the date/time. >>>>> http://www.doodle.com/vd33va5h8iankega >>>>> >>>>> Thanks, >>>>> Josh >>>>> >>>>> -- >>>>> Joshua Hursey >>>>> Postdoctoral Research Associate >>>>> Oak Ridge National Laboratory >>>>> http://users.nccs.gov/~jjhursey >>>>> >>>> >>>> >>>> >>>> -- >>>> Joshua Hursey >>>> Postdoctoral Research Associate >>>> Oak Ridge National Laboratory >>>> http://users.nccs.gov/~jjhursey >>>> >>> >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-rma] Fault Tolerance & RMA Discussion
by Josh Hursey 06 Feb '12

06 Feb '12

We are going to meet from 10-11 am (Eastern) on Feb. 7 to continue our conversation. We will use the same call-in information as before. Thanks, Josh On Thu, Feb 2, 2012 at 3:00 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We made some really good progress on today's call. Attached are some notes > that I took from the call. > > At the end of the call there were a couple of items that we wanted to get > a finer understanding of. As a result we are going to try to setup another > teleconf. > > Below is a doodle poll to pick a date/time: > http://www.doodle.com/kzmiknie8yz4wxkc > > If you are interested in attending this teleconf, please fill out the poll > by 2 pm Eastern on Monday, Feb. 6. > > Thanks, > Josh > > > On Thu, Feb 2, 2012 at 10:01 AM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: > >> Just a reminder that we are meeting today at Noon Eastern to discuss RMA >> in the context of the fault tolerance proposal. >> >> The Run-Through Stabilization proposal can be found attached to the >> ticket: >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… >> >> We will be focusing on section 17.11 of that document. Note that this >> section does not currently explicitly account for the new RMA proposal, but >> we would like to remedy that for the next reading. >> >> Thanks, >> Josh >> >> On Wed, Jan 25, 2012 at 3:15 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >> >>> There was no one date/time that worked for everyone, but I chose a time >>> that worked for most of the respondents. We will meet Thursday, Feb. 2 from >>> 12-1 pm EST/New York to discuss this topic. >>> >>> We can use the following teleconf information: >>> US Toll Free number: 877-801-8130 >>> Toll number: 1-203-692-8690 >>> Access Code: 1044056 >>> >>> Thanks, >>> Josh >>> >>> >>> On Mon, Jan 23, 2012 at 4:33 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >>> >>>> (Cross posted to both the RMA and FT MPI-3 listservs) >>>> >>>> During the FT plenary session at the Jan. MPI Forum meeting it was >>>> recommended that some of the members of the FT group and the RMA group have >>>> a meeting to hash out the precise details of the FT semantics for the RMA >>>> chapter. So I would like to facilitate such a discussion, preferability in >>>> the next week (so we have time to fine tune things before the next forum >>>> meeting). >>>> >>>> In general, we are trying to answer the question "How should RMA >>>> operations behave when a process failure occurs?" The feeling seemed to be >>>> that the current approach is ok (invalidating the window, forcing >>>> recreation/validation), but the statement that the memory exposed in the >>>> window is 'undefined' seemed excessive. The suggestion was to change the >>>> wording to something like "Only the memory associated with a window that >>>> was targeted by an operation that modified it is undefined after process >>>> failure in the group associated with the window." This lead to a >>>> considerable amount of debate in the meeting, so it was suggested that we >>>> take the discussion offline. >>>> >>>> Below is a link to a doodle poll to find a good time for a teleconf. If >>>> you are interested in participating in this discussion, please fill this >>>> poll out by 2 PM Eastern on Wed. Jan 25 so we can set the date/time. >>>> http://www.doodle.com/vd33va5h8iankega >>>> >>>> Thanks, >>>> Josh >>>> >>>> -- >>>> Joshua Hursey >>>> Postdoctoral Research Associate >>>> Oak Ridge National Laboratory >>>> http://users.nccs.gov/~jjhursey >>>> >>> >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-rma] Fault Tolerance & RMA Discussion
by Josh Hursey 02 Feb '12

02 Feb '12

We made some really good progress on today's call. Attached are some notes that I took from the call. At the end of the call there were a couple of items that we wanted to get a finer understanding of. As a result we are going to try to setup another teleconf. Below is a doodle poll to pick a date/time: http://www.doodle.com/kzmiknie8yz4wxkc If you are interested in attending this teleconf, please fill out the poll by 2 pm Eastern on Monday, Feb. 6. Thanks, Josh On Thu, Feb 2, 2012 at 10:01 AM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > Just a reminder that we are meeting today at Noon Eastern to discuss RMA > in the context of the fault tolerance proposal. > > The Run-Through Stabilization proposal can be found attached to the ticket: > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… > > We will be focusing on section 17.11 of that document. Note that this > section does not currently explicitly account for the new RMA proposal, but > we would like to remedy that for the next reading. > > Thanks, > Josh > > On Wed, Jan 25, 2012 at 3:15 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: > >> There was no one date/time that worked for everyone, but I chose a time >> that worked for most of the respondents. We will meet Thursday, Feb. 2 from >> 12-1 pm EST/New York to discuss this topic. >> >> We can use the following teleconf information: >> US Toll Free number: 877-801-8130 >> Toll number: 1-203-692-8690 >> Access Code: 1044056 >> >> Thanks, >> Josh >> >> >> On Mon, Jan 23, 2012 at 4:33 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >> >>> (Cross posted to both the RMA and FT MPI-3 listservs) >>> >>> During the FT plenary session at the Jan. MPI Forum meeting it was >>> recommended that some of the members of the FT group and the RMA group have >>> a meeting to hash out the precise details of the FT semantics for the RMA >>> chapter. So I would like to facilitate such a discussion, preferability in >>> the next week (so we have time to fine tune things before the next forum >>> meeting). >>> >>> In general, we are trying to answer the question "How should RMA >>> operations behave when a process failure occurs?" The feeling seemed to be >>> that the current approach is ok (invalidating the window, forcing >>> recreation/validation), but the statement that the memory exposed in the >>> window is 'undefined' seemed excessive. The suggestion was to change the >>> wording to something like "Only the memory associated with a window that >>> was targeted by an operation that modified it is undefined after process >>> failure in the group associated with the window." This lead to a >>> considerable amount of debate in the meeting, so it was suggested that we >>> take the discussion offline. >>> >>> Below is a link to a doodle poll to find a good time for a teleconf. If >>> you are interested in participating in this discussion, please fill this >>> poll out by 2 PM Eastern on Wed. Jan 25 so we can set the date/time. >>> http://www.doodle.com/vd33va5h8iankega >>> >>> Thanks, >>> Josh >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-rma] Fault Tolerance & RMA Discussion
by Josh Hursey 02 Feb '12

02 Feb '12

Just a reminder that we are meeting today at Noon Eastern to discuss RMA in the context of the fault tolerance proposal. The Run-Through Stabilization proposal can be found attached to the ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… We will be focusing on section 17.11 of that document. Note that this section does not currently explicitly account for the new RMA proposal, but we would like to remedy that for the next reading. Thanks, Josh On Wed, Jan 25, 2012 at 3:15 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > There was no one date/time that worked for everyone, but I chose a time > that worked for most of the respondents. We will meet Thursday, Feb. 2 from > 12-1 pm EST/New York to discuss this topic. > > We can use the following teleconf information: > US Toll Free number: 877-801-8130 > Toll number: 1-203-692-8690 > Access Code: 1044056 > > Thanks, > Josh > > > On Mon, Jan 23, 2012 at 4:33 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: > >> (Cross posted to both the RMA and FT MPI-3 listservs) >> >> During the FT plenary session at the Jan. MPI Forum meeting it was >> recommended that some of the members of the FT group and the RMA group have >> a meeting to hash out the precise details of the FT semantics for the RMA >> chapter. So I would like to facilitate such a discussion, preferability in >> the next week (so we have time to fine tune things before the next forum >> meeting). >> >> In general, we are trying to answer the question "How should RMA >> operations behave when a process failure occurs?" The feeling seemed to be >> that the current approach is ok (invalidating the window, forcing >> recreation/validation), but the statement that the memory exposed in the >> window is 'undefined' seemed excessive. The suggestion was to change the >> wording to something like "Only the memory associated with a window that >> was targeted by an operation that modified it is undefined after process >> failure in the group associated with the window." This lead to a >> considerable amount of debate in the meeting, so it was suggested that we >> take the discussion offline. >> >> Below is a link to a doodle poll to find a good time for a teleconf. If >> you are interested in participating in this discussion, please fill this >> poll out by 2 PM Eastern on Wed. Jan 25 so we can set the date/time. >> http://www.doodle.com/vd33va5h8iankega >> >> Thanks, >> Josh >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0