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

Draft MPI RMA chapter update
by William Gropp 03 May '15

03 May '15

Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. Bill

1 0

Fwd: [Mpi-forum] Agenda for June Meeting
by Jeff Hammond 02 Apr '15

02 Apr '15

I have some important-to-me but not urgent stuff to discuss with the WG but I'm not sure that this is the right meeting for it, given the focus is on 3.1 not 4.0 (at least technical parts). However, since I cannot count on going to France, that would delay these discussions until December, which I'm almost certain I will be able to attend. Best, Jeff ---------- Forwarded message ---------- From: Schulz Martin <schulzm(a)llnl.gov> Date: Wed, Apr 1, 2015 at 8:29 PM Subject: [Mpi-forum] Agenda for June Meeting To: Main mailing list <mpi-forum(a)lists.mpi-forum.org> Hi all, I added a first agenda skeleton for the June meeting to the MPI forum website at: http://meetings.mpi-forum.org/secretary/2015/06/agenda.php The details will change, but due to the nature of the meeting (where we want to ratify MPI 3.1) some things will be different than usual. In particular, we’ll start with a plenary on Monday covering the voting rules (will send a draft for those soon) and the last changes to MPI standard (this way we’ll have extra time to make final fixes). Also, we’ll have two voting blocks, one on Wednesday and one on Thursday. Further, we’ll have the requested discussion on MPI 4.0 on Thursday morning after the votes. Please take this into account when making travel arrangements. This will necessarily limit the time we have for WGs and other plenary issues. We can shift between these two parts as needed, but for now, I reserved a 3/4 day for each. WG chairs, please send me any requests for WG time, plenary time, reading requests and votes rather sooner than later, so we can plan accordingly. Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Jeff Hammond 05 Mar '15

05 Mar '15

As RMA only talks about accumulate between two processes, I don't see any reason to require that these arguments be symmetric, even if that is the most obvious use case. Jeff On Wed, Mar 4, 2015 at 6:35 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > I agree, no_locks seems to have a clear local semantic. accumulate_ops ad > accumulate_ordering need some thought from the WG; I think these were > intended to be provided at all processes. > > ~Jim. > > On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> Actually, I think the wording is clear - no process will target that >> particular window (not window object) with passive target synchronization. >> Thus, as noted in the description, no async handing for passive RMA is >> needed at this process. It says nothing about whether this process can >> issue locks against some other process’s window. >> >> Bill >> >> On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> > >> > If the intention is that it can be local, then the info needs to specify >> > whether it means the process cannot issue locks or whether other processes >> > cannot issue locks on it. Either way, some change is required. I agree >> > this is not ticket-0, and will tell the Forum that the RMA WG will put it on >> > the list of things to discuss. We should do a WG telecon. A number of >> > issues are queued up for discussion at this point. >> > >> > -- Pavan >> > >> >> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> >> >> For the bigger one, yes, this is much harder and absolutely not >> >> ticket-0. no_locks is particularly tricky, because it applies to the >> >> window, not the window object, and hence is defined as local. >> >> >> >> Bill >> >> >> >> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> >> >>> >> >>> There are two questions below. The formatting part (whether to use >> >>> [SAME]) is a smaller issue. The bigger issue is whether we want to say that >> >>> all the remaining info keys no_locks, etc., should be the same on all >> >>> processes. >> >>> >> >>> I want to say that, but: (1) need the chapter committee consensus, and >> >>> (2) I'm not sure it's a ticket-0 change, though we did make that change for >> >>> same_size as ticket-0. >> >>> >> >>> -- Pavan >> >>> >> >>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> >> >>>> wrote: >> >>>> >> >>>> That’s an excellent idea - we should use the same language throughout >> >>>> the standard, and the I/O chapter is probably the best source. >> >>>> >> >>>> Bill >> >>>> >> >>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>>> >> >>>>> >> >>>>> Nathan suggested to use the I/O chapter format where info keys are >> >>>>> annotated with "[SAME]" to indicate that all processes must provide the same >> >>>>> info key. That is probably a ticket-0 change. We need to first agree on >> >>>>> whether we want to do this. >> >>>>> >> >>>>> -- Pavan >> >>>>> >> >>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>>>>> >> >>>>>> >> >>>>>> Folks at Forum complained about the addition to the "same_size" >> >>>>>> info key which added the following phrase: >> >>>>>> >> >>>>>> "and that all processes have provided this info key with the same >> >>>>>> value" >> >>>>>> >> >>>>>> (this change was not a part of any ticket, and was made by the >> >>>>>> chapter committee) >> >>>>>> >> >>>>>> There were two concerns: >> >>>>>> >> >>>>>> 1. This is a backward incompatible change (as in, applications were >> >>>>>> not required to give the same value earlier), though folks understood why >> >>>>>> this is needed. They were OK as long as we add a Errata/Changelog item >> >>>>>> saying so. >> >>>>>> >> >>>>>> 2. The property that all processes should give the same info key >> >>>>>> was true for other keys in that section as well (no_locks, >> >>>>>> accumulate_ordering, accumulate_ops). So the same sentence should be added >> >>>>>> to them as well. >> >>>>>> >> >>>>>> The Forum wants to see a draft of these changes. I'd like to >> >>>>>> propose adding the same phrase ("and that all processes have provided this >> >>>>>> info key with the same value") to the other info keys as well. What do >> >>>>>> folks think? Is this something that we agree on (technically, it is >> >>>>>> possible to have different info keys in the job, but it probably doesn't >> >>>>>> make much sense). >> >>>>>> >> >>>>>> Thoughts? >> >>>>>> >> >>>>>> -- Pavan >> >>>>>> >> >>>>>> -- >> >>>>>> Pavan Balaji ✉️ >> >>>>>> http://www.mcs.anl.gov/~balaji >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> mpiwg-rma mailing list >> >>>>>> mpiwg-rma(a)lists.mpi-forum.org >> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >>>>> >> >>>>> -- >> >>>>> Pavan Balaji ✉️ >> >>>>> http://www.mcs.anl.gov/~balaji >> >>>>> >> >>>>> _______________________________________________ >> >>>>> mpiwg-rma mailing list >> >>>>> mpiwg-rma(a)lists.mpi-forum.org >> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >>>> >> >>>> _______________________________________________ >> >>>> mpiwg-rma mailing list >> >>>> mpiwg-rma(a)lists.mpi-forum.org >> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >>> >> >>> -- >> >>> Pavan Balaji ✉️ >> >>> http://www.mcs.anl.gov/~balaji >> >>> >> >>> _______________________________________________ >> >>> mpiwg-rma mailing list >> >>> mpiwg-rma(a)lists.mpi-forum.org >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> >> >> _______________________________________________ >> >> mpiwg-rma mailing list >> >> mpiwg-rma(a)lists.mpi-forum.org >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> > >> > -- >> > Pavan Balaji ✉️ >> > http://www.mcs.anl.gov/~balaji >> > >> > _______________________________________________ >> > mpiwg-rma mailing list >> > mpiwg-rma(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Rob Latham 05 Mar '15

05 Mar '15

On 03/05/2015 09:19 AM, Balaji, Pavan wrote: > Hi Rob, > >> On Mar 5, 2015, at 9:01 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: >> On 03/04/2015 08:35 PM, Jim Dinan wrote: >>> I agree, no_locks seems to have a clear local semantic. accumulate_ops >>> ad accumulate_ordering need some thought from the WG; I think these were >>> intended to be provided at all processes. >> >> if you are going to call it an MPI_Info, then please follow the rules of MPI_Info objects already well established in the I/O chapter. all processes must specify the same value for a given MPI_Info key. > > I didn't realize we say that in the MPI standard. Can you point me to the location where it says that? > > -- Thanks for forcing me to re-scan the standard. MPI_Info appears in a lot more places than I remembered. I have conflated "The way ROMIO does it" with "the way the standard says", and now see the restriction on identical keys must be a ROMIO thing: page 499 of MPI-3.0: MPI_FILE_SET_INFO sets new values for the hints of the file associated with fh. MPI_FILE_SET_INFO is a collective routine. The info object may be different on each process, but any info entries that an implementation requires to be the same on all processes must appear with the same value in each process’s info object. so you can do whatever you want with MPI_Info objects, apparently. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Balaji, Pavan 05 Mar '15

05 Mar '15

Hi Rob, > On Mar 5, 2015, at 9:01 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: > On 03/04/2015 08:35 PM, Jim Dinan wrote: >> I agree, no_locks seems to have a clear local semantic. accumulate_ops >> ad accumulate_ordering need some thought from the WG; I think these were >> intended to be provided at all processes. > > if you are going to call it an MPI_Info, then please follow the rules of MPI_Info objects already well established in the I/O chapter. all processes must specify the same value for a given MPI_Info key. I didn't realize we say that in the MPI standard. Can you point me to the location where it says that? -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Rob Latham 05 Mar '15

05 Mar '15

On 03/04/2015 08:35 PM, Jim Dinan wrote: > I agree, no_locks seems to have a clear local semantic. accumulate_ops > ad accumulate_ordering need some thought from the WG; I think these were > intended to be provided at all processes. if you are going to call it an MPI_Info, then please follow the rules of MPI_Info objects already well established in the I/O chapter. all processes must specify the same value for a given MPI_Info key. RMA has "things that are like infos but don't follow info rules" they are called "asserts", right? ==rob > > ~Jim. > > On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <wgropp(a)illinois.edu > <mailto:[email protected]>> wrote: > > Actually, I think the wording is clear - no process will target that > particular window (not window object) with passive target > synchronization. Thus, as noted in the description, no async > handing for passive RMA is needed at this process. It says nothing > about whether this process can issue locks against some other > process’s window. > > Bill > > On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji(a)anl.gov > <mailto:[email protected]>> wrote: > > > > > If the intention is that it can be local, then the info needs to > specify whether it means the process cannot issue locks or whether > other processes cannot issue locks on it. Either way, some change > is required. I agree this is not ticket-0, and will tell the Forum > that the RMA WG will put it on the list of things to discuss. We > should do a WG telecon. A number of issues are queued up for > discussion at this point. > > > > -- Pavan > > > >> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu > <mailto:[email protected]>> wrote: > >> > >> For the bigger one, yes, this is much harder and absolutely not > ticket-0. no_locks is particularly tricky, because it applies to > the window, not the window object, and hence is defined as local. > >> > >> Bill > >> > >> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov > <mailto:[email protected]>> wrote: > >> > >>> > >>> There are two questions below. The formatting part (whether to > use [SAME]) is a smaller issue. The bigger issue is whether we want > to say that all the remaining info keys no_locks, etc., should be > the same on all processes. > >>> > >>> I want to say that, but: (1) need the chapter committee > consensus, and (2) I'm not sure it's a ticket-0 change, though we > did make that change for same_size as ticket-0. > >>> > >>> -- Pavan > >>> > >>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu > <mailto:[email protected]>> wrote: > >>>> > >>>> That’s an excellent idea - we should use the same language > throughout the standard, and the I/O chapter is probably the best > source. > >>>> > >>>> Bill > >>>> > >>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov > <mailto:[email protected]>> wrote: > >>>> > >>>>> > >>>>> Nathan suggested to use the I/O chapter format where info > keys are annotated with "[SAME]" to indicate that all processes must > provide the same info key. That is probably a ticket-0 change. We > need to first agree on whether we want to do this. > >>>>> > >>>>> -- Pavan > >>>>> > >>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov > <mailto:[email protected]>> wrote: > >>>>>> > >>>>>> > >>>>>> Folks at Forum complained about the addition to the > "same_size" info key which added the following phrase: > >>>>>> > >>>>>> "and that all processes have provided this info key with the > same value" > >>>>>> > >>>>>> (this change was not a part of any ticket, and was made by > the chapter committee) > >>>>>> > >>>>>> There were two concerns: > >>>>>> > >>>>>> 1. This is a backward incompatible change (as in, > applications were not required to give the same value earlier), > though folks understood why this is needed. They were OK as long as > we add a Errata/Changelog item saying so. > >>>>>> > >>>>>> 2. The property that all processes should give the same info > key was true for other keys in that section as well (no_locks, > accumulate_ordering, accumulate_ops). So the same sentence should > be added to them as well. > >>>>>> > >>>>>> The Forum wants to see a draft of these changes. I'd like > to propose adding the same phrase ("and that all processes have > provided this info key with the same value") to the other info keys > as well. What do folks think? Is this something that we agree on > (technically, it is possible to have different info keys in the job, > but it probably doesn't make much sense). > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> -- Pavan > >>>>>> > >>>>>> -- > >>>>>> Pavan Balaji ✉️ > >>>>>> http://www.mcs.anl.gov/~balaji > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpiwg-rma mailing list > >>>>>> mpiwg-rma(a)lists.mpi-forum.org > <mailto:[email protected]> > >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>>>> > >>>>> -- > >>>>> Pavan Balaji ✉️ > >>>>> http://www.mcs.anl.gov/~balaji > >>>>> > >>>>> _______________________________________________ > >>>>> mpiwg-rma mailing list > >>>>> mpiwg-rma(a)lists.mpi-forum.org > <mailto:[email protected]> > >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>>> > >>>> _______________________________________________ > >>>> mpiwg-rma mailing list > >>>> mpiwg-rma(a)lists.mpi-forum.org > <mailto:[email protected]> > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>> > >>> -- > >>> Pavan Balaji ✉️ > >>> http://www.mcs.anl.gov/~balaji > >>> > >>> _______________________________________________ > >>> mpiwg-rma mailing list > >>> mpiwg-rma(a)lists.mpi-forum.org > <mailto:[email protected]> > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >> > >> _______________________________________________ > >> mpiwg-rma mailing list > >> mpiwg-rma(a)lists.mpi-forum.org <mailto:[email protected]> > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > -- > > Pavan Balaji ✉️ > > http://www.mcs.anl.gov/~balaji > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)lists.mpi-forum.org <mailto:[email protected]> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Jim Dinan 04 Mar '15

04 Mar '15

I agree, no_locks seems to have a clear local semantic. accumulate_ops ad accumulate_ordering need some thought from the WG; I think these were intended to be provided at all processes. ~Jim. On Wed, Mar 4, 2015 at 6:26 PM, William Gropp <wgropp(a)illinois.edu> wrote: > Actually, I think the wording is clear - no process will target that > particular window (not window object) with passive target synchronization. > Thus, as noted in the description, no async handing for passive RMA is > needed at this process. It says nothing about whether this process can > issue locks against some other process’s window. > > Bill > > On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > > > If the intention is that it can be local, then the info needs to specify > whether it means the process cannot issue locks or whether other processes > cannot issue locks on it. Either way, some change is required. I agree > this is not ticket-0, and will tell the Forum that the RMA WG will put it > on the list of things to discuss. We should do a WG telecon. A number of > issues are queued up for discussion at this point. > > > > -- Pavan > > > >> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: > >> > >> For the bigger one, yes, this is much harder and absolutely not > ticket-0. no_locks is particularly tricky, because it applies to the > window, not the window object, and hence is defined as local. > >> > >> Bill > >> > >> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> > >>> > >>> There are two questions below. The formatting part (whether to use > [SAME]) is a smaller issue. The bigger issue is whether we want to say > that all the remaining info keys no_locks, etc., should be the same on all > processes. > >>> > >>> I want to say that, but: (1) need the chapter committee consensus, and > (2) I'm not sure it's a ticket-0 change, though we did make that change for > same_size as ticket-0. > >>> > >>> -- Pavan > >>> > >>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> > wrote: > >>>> > >>>> That’s an excellent idea - we should use the same language throughout > the standard, and the I/O chapter is probably the best source. > >>>> > >>>> Bill > >>>> > >>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >>>> > >>>>> > >>>>> Nathan suggested to use the I/O chapter format where info keys are > annotated with "[SAME]" to indicate that all processes must provide the > same info key. That is probably a ticket-0 change. We need to first agree > on whether we want to do this. > >>>>> > >>>>> -- Pavan > >>>>> > >>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >>>>>> > >>>>>> > >>>>>> Folks at Forum complained about the addition to the "same_size" > info key which added the following phrase: > >>>>>> > >>>>>> "and that all processes have provided this info key with the same > value" > >>>>>> > >>>>>> (this change was not a part of any ticket, and was made by the > chapter committee) > >>>>>> > >>>>>> There were two concerns: > >>>>>> > >>>>>> 1. This is a backward incompatible change (as in, applications were > not required to give the same value earlier), though folks understood why > this is needed. They were OK as long as we add a Errata/Changelog item > saying so. > >>>>>> > >>>>>> 2. The property that all processes should give the same info key > was true for other keys in that section as well (no_locks, > accumulate_ordering, accumulate_ops). So the same sentence should be added > to them as well. > >>>>>> > >>>>>> The Forum wants to see a draft of these changes. I'd like to > propose adding the same phrase ("and that all processes have provided this > info key with the same value") to the other info keys as well. What do > folks think? Is this something that we agree on (technically, it is > possible to have different info keys in the job, but it probably doesn't > make much sense). > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> -- Pavan > >>>>>> > >>>>>> -- > >>>>>> Pavan Balaji ✉️ > >>>>>> http://www.mcs.anl.gov/~balaji > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpiwg-rma mailing list > >>>>>> mpiwg-rma(a)lists.mpi-forum.org > >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>>>> > >>>>> -- > >>>>> Pavan Balaji ✉️ > >>>>> http://www.mcs.anl.gov/~balaji > >>>>> > >>>>> _______________________________________________ > >>>>> mpiwg-rma mailing list > >>>>> mpiwg-rma(a)lists.mpi-forum.org > >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>>> > >>>> _______________________________________________ > >>>> mpiwg-rma mailing list > >>>> mpiwg-rma(a)lists.mpi-forum.org > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >>> > >>> -- > >>> Pavan Balaji ✉️ > >>> http://www.mcs.anl.gov/~balaji > >>> > >>> _______________________________________________ > >>> mpiwg-rma mailing list > >>> mpiwg-rma(a)lists.mpi-forum.org > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > >> > >> _______________________________________________ > >> mpiwg-rma mailing list > >> mpiwg-rma(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > -- > > Pavan Balaji ✉️ > > http://www.mcs.anl.gov/~balaji > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Rolf Rabenseifner 04 Mar '15

04 Mar '15

>>>>>>> 1. This is a backward incompatible change (as in, applications were not required >>>>>>> to give the same value earlier), though folks understood why this is needed. >>>>>>> They were OK as long as we add a Errata/Changelog item saying so. Yes, please send me the errata changelog entry. Proposal: Existing changelog entry 9. Section 11.2.2 on page 405, and MPI-3.0 Section 11.2.2 on page 407. The same_size info key can be used with all window flavors. should be modified into 9. Section 11.2.1 on page xxx, and MPI-3.0 Section 11.2.2 on page 407. The same_size info key can be used with all window flavors, and requires that all processes have provided this info key with the same value. Okay so? Best regards Rolf ----- Original Message ----- > From: "wgropp" <wgropp(a)illinois.edu> > To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > Sent: Thursday, March 5, 2015 12:26:04 AM > Subject: Re: [mpiwg-rma] Changes to the RMA chapter > Actually, I think the wording is clear - no process will target that particular > window (not window object) with passive target synchronization. Thus, as noted > in the description, no async handing for passive RMA is needed at this process. > It says nothing about whether this process can issue locks against some other > process’s window. > > Bill > > On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> If the intention is that it can be local, then the info needs to specify whether >> it means the process cannot issue locks or whether other processes cannot issue >> locks on it. Either way, some change is required. I agree this is not >> ticket-0, and will tell the Forum that the RMA WG will put it on the list of >> things to discuss. We should do a WG telecon. A number of issues are queued >> up for discussion at this point. >> >> -- Pavan >> >>> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>> >>> For the bigger one, yes, this is much harder and absolutely not ticket-0. >>> no_locks is particularly tricky, because it applies to the window, not the >>> window object, and hence is defined as local. >>> >>> Bill >>> >>> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>>> >>>> There are two questions below. The formatting part (whether to use [SAME]) is a >>>> smaller issue. The bigger issue is whether we want to say that all the >>>> remaining info keys no_locks, etc., should be the same on all processes. >>>> >>>> I want to say that, but: (1) need the chapter committee consensus, and (2) I'm >>>> not sure it's a ticket-0 change, though we did make that change for same_size >>>> as ticket-0. >>>> >>>> -- Pavan >>>> >>>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>>> >>>>> That’s an excellent idea - we should use the same language throughout the >>>>> standard, and the I/O chapter is probably the best source. >>>>> >>>>> Bill >>>>> >>>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>>> >>>>>> Nathan suggested to use the I/O chapter format where info keys are annotated >>>>>> with "[SAME]" to indicate that all processes must provide the same info key. >>>>>> That is probably a ticket-0 change. We need to first agree on whether we want >>>>>> to do this. >>>>>> >>>>>> -- Pavan >>>>>> >>>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>>> >>>>>>> >>>>>>> Folks at Forum complained about the addition to the "same_size" info key which >>>>>>> added the following phrase: >>>>>>> >>>>>>> "and that all processes have provided this info key with the same value" >>>>>>> >>>>>>> (this change was not a part of any ticket, and was made by the chapter >>>>>>> committee) >>>>>>> >>>>>>> There were two concerns: >>>>>>> >>>>>>> 1. This is a backward incompatible change (as in, applications were not required >>>>>>> to give the same value earlier), though folks understood why this is needed. >>>>>>> They were OK as long as we add a Errata/Changelog item saying so. >>>>>>> >>>>>>> 2. The property that all processes should give the same info key was true for >>>>>>> other keys in that section as well (no_locks, accumulate_ordering, >>>>>>> accumulate_ops). So the same sentence should be added to them as well. >>>>>>> >>>>>>> The Forum wants to see a draft of these changes. I'd like to propose adding the >>>>>>> same phrase ("and that all processes have provided this info key with the same >>>>>>> value") to the other info keys as well. What do folks think? Is this >>>>>>> something that we agree on (technically, it is possible to have different info >>>>>>> keys in the job, but it probably doesn't make much sense). >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> -- >>>>>>> Pavan Balaji ✉️ >>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-rma mailing list >>>>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>>>> >>>>>> -- >>>>>> Pavan Balaji ✉️ >>>>>> http://www.mcs.anl.gov/~balaji >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-rma mailing list >>>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>>> >>>>> _______________________________________________ >>>>> mpiwg-rma mailing list >>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by William Gropp 04 Mar '15

04 Mar '15

Actually, I think the wording is clear - no process will target that particular window (not window object) with passive target synchronization. Thus, as noted in the description, no async handing for passive RMA is needed at this process. It says nothing about whether this process can issue locks against some other process’s window. Bill On Mar 4, 2015, at 5:17 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > If the intention is that it can be local, then the info needs to specify whether it means the process cannot issue locks or whether other processes cannot issue locks on it. Either way, some change is required. I agree this is not ticket-0, and will tell the Forum that the RMA WG will put it on the list of things to discuss. We should do a WG telecon. A number of issues are queued up for discussion at this point. > > -- Pavan > >> On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> For the bigger one, yes, this is much harder and absolutely not ticket-0. no_locks is particularly tricky, because it applies to the window, not the window object, and hence is defined as local. >> >> Bill >> >> On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> >>> There are two questions below. The formatting part (whether to use [SAME]) is a smaller issue. The bigger issue is whether we want to say that all the remaining info keys no_locks, etc., should be the same on all processes. >>> >>> I want to say that, but: (1) need the chapter committee consensus, and (2) I'm not sure it's a ticket-0 change, though we did make that change for same_size as ticket-0. >>> >>> -- Pavan >>> >>>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>> >>>> That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source. >>>> >>>> Bill >>>> >>>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>>> >>>>> Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. >>>>> >>>>> -- Pavan >>>>> >>>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>> >>>>>> >>>>>> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: >>>>>> >>>>>> "and that all processes have provided this info key with the same value" >>>>>> >>>>>> (this change was not a part of any ticket, and was made by the chapter committee) >>>>>> >>>>>> There were two concerns: >>>>>> >>>>>> 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. >>>>>> >>>>>> 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. >>>>>> >>>>>> The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> -- Pavan >>>>>> >>>>>> -- >>>>>> Pavan Balaji ✉️ >>>>>> http://www.mcs.anl.gov/~balaji >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-rma mailing list >>>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-rma mailing list >>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> -- >>> Pavan Balaji ✉️ >>> http://www.mcs.anl.gov/~balaji >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by Balaji, Pavan 04 Mar '15

04 Mar '15

If the intention is that it can be local, then the info needs to specify whether it means the process cannot issue locks or whether other processes cannot issue locks on it. Either way, some change is required. I agree this is not ticket-0, and will tell the Forum that the RMA WG will put it on the list of things to discuss. We should do a WG telecon. A number of issues are queued up for discussion at this point. -- Pavan > On Mar 4, 2015, at 5:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: > > For the bigger one, yes, this is much harder and absolutely not ticket-0. no_locks is particularly tricky, because it applies to the window, not the window object, and hence is defined as local. > > Bill > > On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> There are two questions below. The formatting part (whether to use [SAME]) is a smaller issue. The bigger issue is whether we want to say that all the remaining info keys no_locks, etc., should be the same on all processes. >> >> I want to say that, but: (1) need the chapter committee consensus, and (2) I'm not sure it's a ticket-0 change, though we did make that change for same_size as ticket-0. >> >> -- Pavan >> >>> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>> >>> That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source. >>> >>> Bill >>> >>> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>>> >>>> Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. >>>> >>>> -- Pavan >>>> >>>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>> >>>>> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: >>>>> >>>>> "and that all processes have provided this info key with the same value" >>>>> >>>>> (this change was not a part of any ticket, and was made by the chapter committee) >>>>> >>>>> There were two concerns: >>>>> >>>>> 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. >>>>> >>>>> 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. >>>>> >>>>> The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). >>>>> >>>>> Thoughts? >>>>> >>>>> -- Pavan >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-rma mailing list >>>>> mpiwg-rma(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0