January 2011 - mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Barrett, Brian W 23 Jan '11

23 Jan '11

Pavan - Before you commit, it would be good to get some favorable reviews. I'm having some trouble figuring out what you merged in from Torsten's document - I can see the purple removes, but given that there was already a bunch of red and dark red, it's a bit difficult to pick out the additions. Would it be possible to either pick a different color for your additions, merge into Torsten's clean document, or list all the changes? Brian On Jan 22, 2011, at 2:39 PM, Pavan Balaji wrote: > All, > > I've attached the merged proposals with the parts that we decided to > merge into proposal 1. > > All of the new additions are in red. The parts that we decided to drop > are in purple (I can easily delete them). > > Torsten: should I commit these changes into the svn repository? > > -- Pavan > > On 01/19/2011 09:51 PM, Torsten Hoefler wrote: >> Hello, >> >> I just updated the version on the page (after more discussions with >> Brian). We have one more comment to discuss at the telecon and one >> change. See: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… >> >> Brian also discovered that the definition of the sync call could be >> misinterpreted to be blocking (if a transfer is in progress from A to B >> and B calls synch, which itself might now depend on the completion of >> the transfer). I think it is defined as nonblocking and thus might >> return a buffer in an inconsistent state (which is now the user's >> problem). Any opinions? >> >> Thanks& All the Best, >> Torsten >> >> PS: The latex diff is: >> >> --- >> @@ -2098,8 +2098,12 @@ >> specifies the set of origin processes for that >> epoch. >> \item >> -Finally, shared and exclusive locks are provided by the two functions >> -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. >> +\hreplace{Finally, shared and exclusive locks are provided by the two functions >> +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, shared lock >> +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, >> +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and >> +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and >> +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } >> Lock synchronization >> is useful for \MPI/ applications that >> emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' >> @@ -3499,7 +3503,11 @@ >> update becomes visible in the public window copy. There is one >> exception to this rule, in the case where the same variable is updated >> by two concurrent accumulates that use the same operation, with the same >> -predefined datatype, on the same window. >> +predefined datatype, on the same window. \hcomment{Brian and Torsten think >> +that this is limiting the usefulness of the programming model >> +significantly, can we relax this (remove the ``same op'' restriction? >> +However, we have to be careful to still allow hardware optimizations of >> +subsets of operations only. Can this be done?} >> \item >> A put or accumulate must not access a target window once a local update >> or a put or accumulate update to another (overlapping) target window >> --- >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > <one-side-2.pdf><ATT00002..txt> -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Pavan Balaji 22 Jan '11

22 Jan '11

Hi Jim, On 01/22/2011 08:19 PM, James Dinan wrote: > Is the justification for the window argument that a system could use > both RMA methods and thus have some windows that are MPI_RMA_UNIFIED and > some that are MPI_RMA_SEPARATE (maybe host memory and accelerator memory > or something like that)? If this is the intent, have we also added a > mechanism (e.g. info argument) to request an RMA mode for a window? Yes, different windows can have different memory models (for example MPI_COMM_SELF might have MPI_RMA_UNIFIED even for non-cache-coherent systems). I'm not sure I understand the need for an "info" argument. An "info" is not used for requesting something from MPI -- it's just to tell MPI what the application will be doing. E.g., you can tell MPI that you don't want to use some features allowing it to optimize other features. I'm assuming that you didn't really mean "info", and meant just a separate parameter that asks for one type of memory model or other. In this case, I'm not sure MPI can give you one or the other on demand. Depending on the hardware platform, you get one or the other. You can query for which one you are getting, which the MPI_RMA_QUERY function is meant to provide. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by James Dinan 22 Jan '11

22 Jan '11

Hi Pavan, Is the justification for the window argument that a system could use both RMA methods and thus have some windows that are MPI_RMA_UNIFIED and some that are MPI_RMA_SEPARATE (maybe host memory and accelerator memory or something like that)? If this is the intent, have we also added a mechanism (e.g. info argument) to request an RMA mode for a window? ~Jim. On 1/22/11 4:58 PM, Pavan Balaji wrote: > > Btw, the MPI_RMA_QUERY function still seems to take a "datatype" and > "op" argument. As we have discussed in the past many telecons and > Forums, this should not be required. It should only take the window > input argument, and the result as an output argument. > > -- Pavan > > On 01/22/2011 03:39 PM, Pavan Balaji wrote: >> All, >> >> I've attached the merged proposals with the parts that we decided to >> merge into proposal 1. >> >> All of the new additions are in red. The parts that we decided to drop >> are in purple (I can easily delete them). >> >> Torsten: should I commit these changes into the svn repository? >> >> -- Pavan >> >> On 01/19/2011 09:51 PM, Torsten Hoefler wrote: >>> Hello, >>> >>> I just updated the version on the page (after more discussions with >>> Brian). We have one more comment to discuss at the telecon and one >>> change. See: >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… >>> >>> >>> Brian also discovered that the definition of the sync call could be >>> misinterpreted to be blocking (if a transfer is in progress from A to B >>> and B calls synch, which itself might now depend on the completion of >>> the transfer). I think it is defined as nonblocking and thus might >>> return a buffer in an inconsistent state (which is now the user's >>> problem). Any opinions? >>> >>> Thanks& All the Best, >>> Torsten >>> >>> PS: The latex diff is: >>> >>> --- >>> @@ -2098,8 +2098,12 @@ >>> specifies the set of origin processes for that >>> epoch. >>> \item >>> -Finally, shared and exclusive locks are provided by the two functions >>> -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. >>> +\hreplace{Finally, shared and exclusive locks are provided by the >>> two functions >>> +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, >>> shared lock >>> +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, >>> +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and >>> +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and >>> +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } >>> Lock synchronization >>> is useful for \MPI/ applications that >>> emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' >>> @@ -3499,7 +3503,11 @@ >>> update becomes visible in the public window copy. There is one >>> exception to this rule, in the case where the same variable is updated >>> by two concurrent accumulates that use the same operation, with the same >>> -predefined datatype, on the same window. >>> +predefined datatype, on the same window. \hcomment{Brian and Torsten >>> think >>> +that this is limiting the usefulness of the programming model >>> +significantly, can we relax this (remove the ``same op'' restriction? >>> +However, we have to be careful to still allow hardware optimizations of >>> +subsets of operations only. Can this be done?} >>> \item >>> A put or accumulate must not access a target window once a local update >>> or a put or accumulate update to another (overlapping) target window >>> --- >>> >> >> >> >> _______________________________________________ >> 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] RMA telecon, 1/24, noon Central
by Pavan Balaji 22 Jan '11

22 Jan '11

Btw, the MPI_RMA_QUERY function still seems to take a "datatype" and "op" argument. As we have discussed in the past many telecons and Forums, this should not be required. It should only take the window input argument, and the result as an output argument. -- Pavan On 01/22/2011 03:39 PM, Pavan Balaji wrote: > All, > > I've attached the merged proposals with the parts that we decided to > merge into proposal 1. > > All of the new additions are in red. The parts that we decided to drop > are in purple (I can easily delete them). > > Torsten: should I commit these changes into the svn repository? > > -- Pavan > > On 01/19/2011 09:51 PM, Torsten Hoefler wrote: >> Hello, >> >> I just updated the version on the page (after more discussions with >> Brian). We have one more comment to discuss at the telecon and one >> change. See: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… >> >> Brian also discovered that the definition of the sync call could be >> misinterpreted to be blocking (if a transfer is in progress from A to B >> and B calls synch, which itself might now depend on the completion of >> the transfer). I think it is defined as nonblocking and thus might >> return a buffer in an inconsistent state (which is now the user's >> problem). Any opinions? >> >> Thanks& All the Best, >> Torsten >> >> PS: The latex diff is: >> >> --- >> @@ -2098,8 +2098,12 @@ >> specifies the set of origin processes for that >> epoch. >> \item >> -Finally, shared and exclusive locks are provided by the two functions >> -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. >> +\hreplace{Finally, shared and exclusive locks are provided by the two functions >> +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, shared lock >> +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, >> +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and >> +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and >> +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } >> Lock synchronization >> is useful for \MPI/ applications that >> emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' >> @@ -3499,7 +3503,11 @@ >> update becomes visible in the public window copy. There is one >> exception to this rule, in the case where the same variable is updated >> by two concurrent accumulates that use the same operation, with the same >> -predefined datatype, on the same window. >> +predefined datatype, on the same window. \hcomment{Brian and Torsten think >> +that this is limiting the usefulness of the programming model >> +significantly, can we relax this (remove the ``same op'' restriction? >> +However, we have to be careful to still allow hardware optimizations of >> +subsets of operations only. Can this be done?} >> \item >> A put or accumulate must not access a target window once a local update >> or a put or accumulate update to another (overlapping) target window >> --- >> > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Pavan Balaji 22 Jan '11

22 Jan '11

All, I've attached the merged proposals with the parts that we decided to merge into proposal 1. All of the new additions are in red. The parts that we decided to drop are in purple (I can easily delete them). Torsten: should I commit these changes into the svn repository? -- Pavan On 01/19/2011 09:51 PM, Torsten Hoefler wrote: > Hello, > > I just updated the version on the page (after more discussions with > Brian). We have one more comment to discuss at the telecon and one > change. See: > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… > > Brian also discovered that the definition of the sync call could be > misinterpreted to be blocking (if a transfer is in progress from A to B > and B calls synch, which itself might now depend on the completion of > the transfer). I think it is defined as nonblocking and thus might > return a buffer in an inconsistent state (which is now the user's > problem). Any opinions? > > Thanks& All the Best, > Torsten > > PS: The latex diff is: > > --- > @@ -2098,8 +2098,12 @@ > specifies the set of origin processes for that > epoch. > \item > -Finally, shared and exclusive locks are provided by the two functions > -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. > +\hreplace{Finally, shared and exclusive locks are provided by the two functions > +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, shared lock > +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, > +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and > +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and > +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } > Lock synchronization > is useful for \MPI/ applications that > emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' > @@ -3499,7 +3503,11 @@ > update becomes visible in the public window copy. There is one > exception to this rule, in the case where the same variable is updated > by two concurrent accumulates that use the same operation, with the same > -predefined datatype, on the same window. > +predefined datatype, on the same window. \hcomment{Brian and Torsten think > +that this is limiting the usefulness of the programming model > +significantly, can we relax this (remove the ``same op'' restriction? > +However, we have to be careful to still allow hardware optimizations of > +subsets of operations only. Can this be done?} > \item > A put or accumulate must not access a target window once a local update > or a put or accumulate update to another (overlapping) target window > --- > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Torsten Hoefler 19 Jan '11

19 Jan '11

Hello, I just updated the version on the page (after more discussions with Brian). We have one more comment to discuss at the telecon and one change. See: https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… Brian also discovered that the definition of the sync call could be misinterpreted to be blocking (if a transfer is in progress from A to B and B calls synch, which itself might now depend on the completion of the transfer). I think it is defined as nonblocking and thus might return a buffer in an inconsistent state (which is now the user's problem). Any opinions? Thanks & All the Best, Torsten PS: The latex diff is: --- @@ -2098,8 +2098,12 @@ specifies the set of origin processes for that epoch. \item -Finally, shared and exclusive locks are provided by the two functions -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. +\hreplace{Finally, shared and exclusive locks are provided by the two functions +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, shared lock +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } Lock synchronization is useful for \MPI/ applications that emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' @@ -3499,7 +3503,11 @@ update becomes visible in the public window copy. There is one exception to this rule, in the case where the same variable is updated by two concurrent accumulates that use the same operation, with the same -predefined datatype, on the same window. +predefined datatype, on the same window. \hcomment{Brian and Torsten think +that this is limiting the usefulness of the programming model +significantly, can we relax this (remove the ``same op'' restriction? +However, we have to be careful to still allow hardware optimizations of +subsets of operations only. Can this be done?} \item A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window --- -- 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] RMA telecon, 1/24, noon Central
by Torsten Hoefler 18 Jan '11

18 Jan '11

Thanks Rajeev, I uploaded a new version to the Wiki which includes all changes we made at the last meeting and numerous fixes based on comments by Brian. I also added/updated some comments to be discussed during the telecon. As Bill mentioned, we should strive to erase all of them during the next telecon. Please review the current document and let me know if you have any comments. I also attached a "clean" version which reflects the final version without change macros. It is called one-side-2-clean.pdf. Any comments are welcome! All the Best, Torsten On Mon, Jan 17, 2011 at 05:22:07PM -0600, Rajeev Thakur wrote: > We will have our next RMA telecon on Mon, Jan 24, at noon Central. > > Dial-in Number: 866-654-6744 > International Dial-in Number: 1-517-308-8226 > Participant Access code: 6086006 > > Rajeev > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > -- 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

[Mpi3-rma] RMA telecon, 1/24, noon Central
by Rajeev Thakur 17 Jan '11

17 Jan '11

We will have our next RMA telecon on Mon, Jan 24, at noon Central. Dial-in Number: 866-654-6744 International Dial-in Number: 1-517-308-8226 Participant Access code: 6086006 Rajeev

1 0