mpiwg-rma

Download

[email protected]

February 2019

1 participants
2 discussions

Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018
by Rolf Rabenseifner 19 Feb '19

19 Feb '19

Dear Pavan and all, I just found the ticket from Bill, Sep. 19, 2016 and labeled it with wg-rma, MPI-4.0, Chattanooga, reading. Still within Monday Feb. 18, 2019 deadline for Chattanooga when using Hawaiian timezone ;-) Therefore, I'll also send out the Forum-Mail for the reading before midnight on Hawaii. I hope, that this is okay for you all. The further going solution, as proposed by Pavan should be discussed independently, because also allowing MPI_Win_create, i.e., removing the whole restriction, may have Performance aspects if the progress implementation of an MPI library is not identical for MPI_Win_create and MPI_Win_create_dynamic + MPI_Win_attach. Pavan, I hope that you can add the pull request for this ticket today. As change-log, I propose \item Section~\ref{sec:1sided-lock} on page~\pageref{sec:1sided-lock}. \newline The rule that implementors may restrict the use of \RMA/ communication that is synchronized with \mpifunc{MPI\_WIN\_LOCK}, \mpifunc{MPI\_WIN\_LOCK\_ALL} and other lock calls to windows in memory allocated by \mpifunc{MPI\_ALLOC\_MEM}, \mpifunc{MPI\_WIN\_ALLOCATE}, or attached with \mpifunc{MPI\_WIN\_ATTACH}, is extended by memory allocated with \mpifunc{MPI\_WIN\_ALLOCATE\_SHARED}. ---- With this, we have the change-log also visible in the index entry of all related routines, which helps that people can find the change-log. Best regards Rolf ----- Original Message ----- > From: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > To: "Pavan Balaji" <balaji(a)anl.gov> > Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "MPI WG Remote Memory Access working group" > <mpiwg-rma(a)lists.mpi-forum.org> > Sent: Sunday, February 17, 2019 1:15:53 PM > Subject: Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018 >> +1 on removing that text. The intent was to allow Win_create too, which we >> somehow missed. > The original MPI-2 intent was, to allow only memories that were allocated by > an MPI library routine and ***not*** just handed over by the user (as with > MPI_WIN_CREATE). > This means, MPI_WIN_CREATE was originally never intented. > > In MPI-2, it was therefore only MPI_ALLOC_MEM. > I do not understand, why MPI_WIN_ATTACH was added to the list. > And I expect that MPI_WIN_ALLOCATE_SHARED was overseen. > But as Jeff said, with MPI_WIN_ATTACH in the list, > this restriction does not make sense anymore. > > Is there a ticket resolving this Problem in MPI-4.0 > (Deadline seems to be today (or Monday noon?). > > Best regards > Rolf > > ----- Original Message ----- >> From: "Pavan Balaji" <balaji(a)anl.gov> >> To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> >> Cc: "Pavan Balaji" <balaji(a)anl.gov>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, >> "Jeff Hammond" <jeff.science(a)gmail.com> >> Sent: Wednesday, September 26, 2018 6:16:25 PM >> Subject: Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of >> MPI RMA WG meeting on Sept 21, 2018 > >>> On Sep 25, 2018, at 9:38 PM, Jeff Hammond via mpiwg-rma >>> <mpiwg-rma(a)lists.mpi-forum.org> wrote: >>> Implementors may restrict the use of RMA communication that >>> is synchronized by lock calls to windows in memory allocated >>> by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), >>> MPI_WIN_ALLOCATE_SHARED (Section 11.2.3), >>> or attached with MPI_WIN_ATTACH (Section 11.2.4). >>> Locks can be used portably only in such memory. >>> >>> >>> >>> I am not certain that this change is consistent with the original intent, but we >>> should just remove this text, because it does not make sense anymore. If >>> MPI_Win_attach is sufficient to allow locks, then MPI_Win_create should be >>> there, because one can implement MPI_Win_create in terms of >>> MPI_Win_create_dynamic+MPI_Win_attach. >> >> +1 on removing that text. The intent was to allow Win_create too, which we >> somehow missed. >> >> -- Pavan > > -- > 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) . > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/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] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018
by Rolf Rabenseifner 17 Feb '19

17 Feb '19

> +1 on removing that text. The intent was to allow Win_create too, which we > somehow missed. The original MPI-2 intent was, to allow only memories that were allocated by an MPI library routine and ***not*** just handed over by the user (as with MPI_WIN_CREATE). This means, MPI_WIN_CREATE was originally never intented. In MPI-2, it was therefore only MPI_ALLOC_MEM. I do not understand, why MPI_WIN_ATTACH was added to the list. And I expect that MPI_WIN_ALLOCATE_SHARED was overseen. But as Jeff said, with MPI_WIN_ATTACH in the list, this restriction does not make sense anymore. Is there a ticket resolving this Problem in MPI-4.0 (Deadline seems to be today (or Monday noon?). Best regards Rolf ----- Original Message ----- > From: "Pavan Balaji" <balaji(a)anl.gov> > To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > Cc: "Pavan Balaji" <balaji(a)anl.gov>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Jeff Hammond" <jeff.science(a)gmail.com> > Sent: Wednesday, September 26, 2018 6:16:25 PM > Subject: Re: [mpiwg-rma] Bugs in RMA in current MPI standard - Re: Summary of MPI RMA WG meeting on Sept 21, 2018 >> On Sep 25, 2018, at 9:38 PM, Jeff Hammond via mpiwg-rma >> <mpiwg-rma(a)lists.mpi-forum.org> wrote: >> Implementors may restrict the use of RMA communication that >> is synchronized by lock calls to windows in memory allocated >> by MPI_ALLOC_MEM (Section 8.2), MPI_WIN_ALLOCATE (Section 11.2.2), >> MPI_WIN_ALLOCATE_SHARED (Section 11.2.3), >> or attached with MPI_WIN_ATTACH (Section 11.2.4). >> Locks can be used portably only in such memory. >> >> >> >> I am not certain that this change is consistent with the original intent, but we >> should just remove this text, because it does not make sense anymore. If >> MPI_Win_attach is sufficient to allow locks, then MPI_Win_create should be >> there, because one can implement MPI_Win_create in terms of >> MPI_Win_create_dynamic+MPI_Win_attach. > > +1 on removing that text. The intent was to allow Win_create too, which we > somehow missed. > > -- Pavan -- 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