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

Re: [mpiwg-rma] RMA Errata
by Rolf Rabenseifner 22 Jan '15

22 Jan '15

> #1 -- ... > lock/unlock). I believe this was an oversight, and we intended that the > load/store operations target the rank that allocated the memory. I expect that this is a restriction that is not needed and that does not fit to the idea and reality of shared memory. There should be no difference on p processes between a program that A) allocates with MPI_Win_allocate_shared on each process n bytes, and then all process call MPI_Win_shared_query to get the baseptr of process rank 0 and they use this baseptr for all loads and stores. and B) that allocates on all processes zero Bytes, except on one process where n*p bytes are allocated, and then /as in A) all process call MPI_Win_shared_query to get the baseptr of process rank 0 and they use this baseptr for all loads and stores. Therefore, a better solution is needed. Rolf ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > Sent: Wednesday, January 21, 2015 6:34:16 PM > Subject: Re: [mpiwg-rma] RMA Errata > > #1 -- The effective target rank of load/store operations is currently not > defined on shared memory windows. That statement may seem like nonsense. > However, it is important for situations where load/store operations interact > with RMA operations that do have an explicit target rank (e.g. > lock/unlock). I believe this was an oversight, and we intended that the > load/store operations target the rank that allocated the memory. > > #2 -- Yes, sounds like we are in agreement > > ~Jim. > > On Mon, Jan 19, 2015 at 2:44 PM, William Gropp < wgropp(a)illinois.edu > wrote: > > > > My preference is that load/store access follows the language rules for shared > memory (I think that is what #1 means). I don’t think anything else is > viable. > > For #2, I think so - again, the issue here is that while Unified promises > “eventually”, real programs usually need some certainty, and for that, an > explicit RMA synchronization is required. > > Bill > > On Jan 19, 2015, at 8:42 AM, Jim Dinan < james.dinan(a)gmail.com > wrote: > > > > > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan < james.dinan(a)gmail.com > wrote: > > > > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following errata > would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared memory > windows. This is needed so that synchronization operations (e.g. > lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory in > the unified memory model, there are still public and private views that must > be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future > discussion? > > Cheers, > ~Jim. > > _______________________________________________ > 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 -- 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] RMA Errata
by Jim Dinan 21 Jan '15

21 Jan '15

#1 -- The effective target rank of load/store operations is currently not defined on shared memory windows. That statement may seem like nonsense. However, it is important for situations where load/store operations interact with RMA operations that do have an explicit target rank (e.g. lock/unlock). I believe this was an oversight, and we intended that the load/store operations target the rank that allocated the memory. #2 -- Yes, sounds like we are in agreement ~Jim. On Mon, Jan 19, 2015 at 2:44 PM, William Gropp <wgropp(a)illinois.edu> wrote: > My preference is that load/store access follows the language rules for > shared memory (I think that is what #1 means). I don’t think anything else > is viable. > > For #2, I think so - again, the issue here is that while Unified promises > “eventually”, real programs usually need some certainty, and for that, an > explicit RMA synchronization is required. > > Bill > > On Jan 19, 2015, at 8:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> Hi All, >> >> Reviewing my notes from the WG meeting, it appears that the following >> errata would clarify many misunderstandings of the MPI-3 RMA spec: >> >> 1) Clarify the target process rank for load/store operations on shared >> memory windows. This is needed so that synchronization operations (e.g. >> lock/unlock and PSCW) are well defined on shared memory windows. >> >> 2) Clarify that that while there is one copy of the window data in memory >> in the unified memory model, there are still public and private views that >> must be synchronized according to the RMA semantics. >> >> Is there enough support for these that they should be captured for future >> discussion? >> >> Cheers, >> ~Jim. >> > > _______________________________________________ > 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] RMA Errata
by William Gropp 19 Jan '15

19 Jan '15

My preference is that load/store access follows the language rules for shared memory (I think that is what #1 means). I don’t think anything else is viable. For #2, I think so - again, the issue here is that while Unified promises “eventually”, real programs usually need some certainty, and for that, an explicit RMA synchronization is required. Bill On Jan 19, 2015, at 8:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Bumping this thread for progress. Please take a look a the two errata suggestions that I captured from the December meeting. If folks feel that this is a good direction, I can convert the informal text below into proper errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following errata would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared memory windows. This is needed so that synchronization operations (e.g. lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory in the unified memory model, there are still public and private views that must be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future discussion? > > Cheers, > ~Jim. > > _______________________________________________ > 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] RMA Errata
by Jeff Hammond 19 Jan '15

19 Jan '15

My parents took the same lazy approach as the MPI Forum regarding asynchronous progress in RMA, so I can only work on the RMA chapter when I am communicating with Forum members via email or telecon. This makes me totally useless but I still tell my friends that I am a high-quality implementation. I fully support #2. I'm sure that #1 makes sense but since PSCW makes my brain hurt and I stopped using point-wise Lock/Unlock as soon as MPI-3 dropped, I haven't thought about it much. Best, Jeff On Mon, Jan 19, 2015 at 6:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >> Hi All, >> >> Reviewing my notes from the WG meeting, it appears that the following >> errata would clarify many misunderstandings of the MPI-3 RMA spec: >> >> 1) Clarify the target process rank for load/store operations on shared >> memory windows. This is needed so that synchronization operations (e.g. >> lock/unlock and PSCW) are well defined on shared memory windows. >> >> 2) Clarify that that while there is one copy of the window data in memory >> in the unified memory model, there are still public and private views that >> must be synchronized according to the RMA semantics. >> >> Is there enough support for these that they should be captured for future >> discussion? >> >> Cheers, >> ~Jim. > > > > _______________________________________________ > 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] RMA Errata
by Jim Dinan 19 Jan '15

19 Jan '15

Bumping this thread for progress. Please take a look a the two errata suggestions that I captured from the December meeting. If folks feel that this is a good direction, I can convert the informal text below into proper errata proposals. ~Jim. On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following > errata would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared > memory windows. This is needed so that synchronization operations (e.g. > lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory > in the unified memory model, there are still public and private views that > must be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future > discussion? > > Cheers, > ~Jim. >

1 0

RMA Errata
by Jim Dinan 17 Dec '14

17 Dec '14

Hi All, Reviewing my notes from the WG meeting, it appears that the following errata would clarify many misunderstandings of the MPI-3 RMA spec: 1) Clarify the target process rank for load/store operations on shared memory windows. This is needed so that synchronization operations (e.g. lock/unlock and PSCW) are well defined on shared memory windows. 2) Clarify that that while there is one copy of the window data in memory in the unified memory model, there are still public and private views that must be synchronized according to the RMA semantics. Is there enough support for these that they should be captured for future discussion? Cheers, ~Jim.

1 0

Re: [mpiwg-rma] iflush ticket needed
by Jeff Hammond 12 Dec '14

12 Dec '14

if put 2 is allowed to overtake put 1, then that basically says that only the last iflush in a series has an effect, which makes this feature less useful. what you seem to be saying is that you want this: put 1 iflush -> r1 put 2 iflush -> r2 wait(r1,r1) to be no different than this: put 1 put 2 iflush -> r wait(r) because that's what you'd get if you allow the iflush calls to reorder. jeff On Fri, Dec 12, 2014 at 4:50 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > "Not allowed to overtake" is hard depending on how the MPI implementation is written. This is even more painful if this test used multiple threads. > > Anyway, I'll make slides. > > -- Pavan > >> On Dec 12, 2014, at 4:54 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >>> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. >> >> I agree with my understanding of Bill's comments, which is that >> waiting on the iflush request is not a synchronization point with >> respect to any operations issued after the iflush was called. >> >>> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? >> >> They should not be allowed to finish out of order. >> >>> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? >> >> You mean this? >> >> put 1 >> iflush -> r1 >> put 2 >> iflush -> r2 >> wait(r1,r1) >> >> The only reasonable way to define this is that put 1 is flushed before >> put 2. Obviously, with put-flush-put-flush today, the second put can >> overwrite the first. However, it should not be permitted to overtake >> it. >> >> Jeff >> >> >> On Fri, Dec 12, 2014 at 2:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>> I can make slides to describe the options. I don't want to spend time making a standard-level document, since we are inevitably going to argue about and change. >>> >>> FWIW, the below definition is what I'd expect, but it still doesn't address the other questions in my list. >>> >>> -- Pavan >>> >>>> On Dec 12, 2014, at 3:40 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>> >>>> I’d like to see a document that describes the options, then arrange a telecon with the interested folks (I do find a well-prepared telecon useful). The telecon need not involve the entire WG. >>>> >>>> As a start, I’d define completing an “iflush” as completing RMA operations initiated before the iflush was called. It would say nothing (either way) about operations initiated after the iflush. Most of the answers should be derivable from this definition, which matches the other uses of nonblocking in MPI. >>>> >>>> Bill >>>> >>>> On Dec 11, 2014, at 11:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>>> >>>>> Can we discuss this on the WG telecon (which the chair needs to restart)? >>>>> >>>>> I'd like to first put together rough thoughts on the semantics in slides before writing up text. Specific issues to clarify: >>>>> >>>>> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. >>>>> >>>>> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? >>>>> >>>>> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? >>>>> >>>>> There might be more issues that need clarification too. I'm happy to make slides discussing a first draft of these (and more perhaps), but I don't want the discussion to be over email. >>>>> >>>>> -- Pavan >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Dec 10, 2014, at 2:57 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>>>> >>>>>> We really need a ticket i.e. a substantive written proposal for >>>>>> iflush, etc. in order to make progress on the umbrella topic that >>>>>> includes it and #459. >>>>>> >>>>>> Pavan: Please let me know when you will have something for this. >>>>>> >>>>>> Jeff >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >>>>>> Date: Wed, Dec 10, 2014 at 11:11 AM >>>>>> Subject: Re: [MPI Forum] #459: RMA sync ops with vector of windows >>>>>> To: >>>>>> >>>>>> >>>>>> #459: RMA sync ops with vector of windows >>>>>> -------------------------------------+------------------------------------- >>>>>> Reporter: jhammond | Owner: jhammond >>>>>> Type: New routine(s) | Status: assigned >>>>>> Priority: Not ready / author | Milestone: 2014/12/08 >>>>>> rework | California, USA >>>>>> Version: MPI 4.0 | Resolution: >>>>>> Keywords: RMA | Implementation status: Waiting >>>>>> -------------------------------------+------------------------------------- >>>>>> >>>>>> Comment (by gropp): >>>>>> >>>>>> The WG found this interesting, but notes that there are alternatives that >>>>>> may provide the same capability. These include nonblocking flush. In a >>>>>> straw vote, iflush received 11 votes and nflush received 3; in contrast, >>>>>> nsync received 9 and isync received 4. >>>>>> >>>>>> -- >>>>>> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/459#comment:3> >>>>>> MPI Forum <https://svn.mpi-forum.org/> >>>>>> MPI Forum >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Hammond >>>>>> jeff.science(a)gmail.com >>>>>> http://jeffhammond.github.io/ >>>>>> _______________________________________________ >>>>>> 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 >>> >>> -- >>> 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 >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> 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 -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] iflush ticket needed
by Balaji, Pavan 12 Dec '14

12 Dec '14

"Not allowed to overtake" is hard depending on how the MPI implementation is written. This is even more painful if this test used multiple threads. Anyway, I'll make slides. -- Pavan > On Dec 12, 2014, at 4:54 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. > > I agree with my understanding of Bill's comments, which is that > waiting on the iflush request is not a synchronization point with > respect to any operations issued after the iflush was called. > >> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? > > They should not be allowed to finish out of order. > >> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? > > You mean this? > > put 1 > iflush -> r1 > put 2 > iflush -> r2 > wait(r1,r1) > > The only reasonable way to define this is that put 1 is flushed before > put 2. Obviously, with put-flush-put-flush today, the second put can > overwrite the first. However, it should not be permitted to overtake > it. > > Jeff > > > On Fri, Dec 12, 2014 at 2:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> I can make slides to describe the options. I don't want to spend time making a standard-level document, since we are inevitably going to argue about and change. >> >> FWIW, the below definition is what I'd expect, but it still doesn't address the other questions in my list. >> >> -- Pavan >> >>> On Dec 12, 2014, at 3:40 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>> >>> I’d like to see a document that describes the options, then arrange a telecon with the interested folks (I do find a well-prepared telecon useful). The telecon need not involve the entire WG. >>> >>> As a start, I’d define completing an “iflush” as completing RMA operations initiated before the iflush was called. It would say nothing (either way) about operations initiated after the iflush. Most of the answers should be derivable from this definition, which matches the other uses of nonblocking in MPI. >>> >>> Bill >>> >>> On Dec 11, 2014, at 11:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>>> >>>> Can we discuss this on the WG telecon (which the chair needs to restart)? >>>> >>>> I'd like to first put together rough thoughts on the semantics in slides before writing up text. Specific issues to clarify: >>>> >>>> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. >>>> >>>> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? >>>> >>>> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? >>>> >>>> There might be more issues that need clarification too. I'm happy to make slides discussing a first draft of these (and more perhaps), but I don't want the discussion to be over email. >>>> >>>> -- Pavan >>>> >>>> Sent from my iPhone >>>> >>>>> On Dec 10, 2014, at 2:57 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>>> >>>>> We really need a ticket i.e. a substantive written proposal for >>>>> iflush, etc. in order to make progress on the umbrella topic that >>>>> includes it and #459. >>>>> >>>>> Pavan: Please let me know when you will have something for this. >>>>> >>>>> Jeff >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >>>>> Date: Wed, Dec 10, 2014 at 11:11 AM >>>>> Subject: Re: [MPI Forum] #459: RMA sync ops with vector of windows >>>>> To: >>>>> >>>>> >>>>> #459: RMA sync ops with vector of windows >>>>> -------------------------------------+------------------------------------- >>>>> Reporter: jhammond | Owner: jhammond >>>>> Type: New routine(s) | Status: assigned >>>>> Priority: Not ready / author | Milestone: 2014/12/08 >>>>> rework | California, USA >>>>> Version: MPI 4.0 | Resolution: >>>>> Keywords: RMA | Implementation status: Waiting >>>>> -------------------------------------+------------------------------------- >>>>> >>>>> Comment (by gropp): >>>>> >>>>> The WG found this interesting, but notes that there are alternatives that >>>>> may provide the same capability. These include nonblocking flush. In a >>>>> straw vote, iflush received 11 votes and nflush received 3; in contrast, >>>>> nsync received 9 and isync received 4. >>>>> >>>>> -- >>>>> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/459#comment:3> >>>>> MPI Forum <https://svn.mpi-forum.org/> >>>>> MPI Forum >>>>> >>>>> >>>>> -- >>>>> Jeff Hammond >>>>> jeff.science(a)gmail.com >>>>> http://jeffhammond.github.io/ >>>>> _______________________________________________ >>>>> 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 >> >> -- >> 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 > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > 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

Re: [mpiwg-rma] iflush ticket needed
by Jeff Hammond 12 Dec '14

12 Dec '14

> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. I agree with my understanding of Bill's comments, which is that waiting on the iflush request is not a synchronization point with respect to any operations issued after the iflush was called. > 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? They should not be allowed to finish out of order. > 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? You mean this? put 1 iflush -> r1 put 2 iflush -> r2 wait(r1,r1) The only reasonable way to define this is that put 1 is flushed before put 2. Obviously, with put-flush-put-flush today, the second put can overwrite the first. However, it should not be permitted to overtake it. Jeff On Fri, Dec 12, 2014 at 2:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > I can make slides to describe the options. I don't want to spend time making a standard-level document, since we are inevitably going to argue about and change. > > FWIW, the below definition is what I'd expect, but it still doesn't address the other questions in my list. > > -- Pavan > >> On Dec 12, 2014, at 3:40 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> I’d like to see a document that describes the options, then arrange a telecon with the interested folks (I do find a well-prepared telecon useful). The telecon need not involve the entire WG. >> >> As a start, I’d define completing an “iflush” as completing RMA operations initiated before the iflush was called. It would say nothing (either way) about operations initiated after the iflush. Most of the answers should be derivable from this definition, which matches the other uses of nonblocking in MPI. >> >> Bill >> >> On Dec 11, 2014, at 11:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> >>> Can we discuss this on the WG telecon (which the chair needs to restart)? >>> >>> I'd like to first put together rough thoughts on the semantics in slides before writing up text. Specific issues to clarify: >>> >>> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. >>> >>> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? >>> >>> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? >>> >>> There might be more issues that need clarification too. I'm happy to make slides discussing a first draft of these (and more perhaps), but I don't want the discussion to be over email. >>> >>> -- Pavan >>> >>> Sent from my iPhone >>> >>>> On Dec 10, 2014, at 2:57 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> >>>> We really need a ticket i.e. a substantive written proposal for >>>> iflush, etc. in order to make progress on the umbrella topic that >>>> includes it and #459. >>>> >>>> Pavan: Please let me know when you will have something for this. >>>> >>>> Jeff >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >>>> Date: Wed, Dec 10, 2014 at 11:11 AM >>>> Subject: Re: [MPI Forum] #459: RMA sync ops with vector of windows >>>> To: >>>> >>>> >>>> #459: RMA sync ops with vector of windows >>>> -------------------------------------+------------------------------------- >>>> Reporter: jhammond | Owner: jhammond >>>> Type: New routine(s) | Status: assigned >>>> Priority: Not ready / author | Milestone: 2014/12/08 >>>> rework | California, USA >>>> Version: MPI 4.0 | Resolution: >>>> Keywords: RMA | Implementation status: Waiting >>>> -------------------------------------+------------------------------------- >>>> >>>> Comment (by gropp): >>>> >>>> The WG found this interesting, but notes that there are alternatives that >>>> may provide the same capability. These include nonblocking flush. In a >>>> straw vote, iflush received 11 votes and nflush received 3; in contrast, >>>> nsync received 9 and isync received 4. >>>> >>>> -- >>>> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/459#comment:3> >>>> MPI Forum <https://svn.mpi-forum.org/> >>>> MPI Forum >>>> >>>> >>>> -- >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>>> http://jeffhammond.github.io/ >>>> _______________________________________________ >>>> 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 > > -- > 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 -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] iflush ticket needed
by Gropp, William D 12 Dec '14

12 Dec '14

A standard level doc is not needed - but something akin to what I wrote on the info renaming would help. And I think the answers to your question follow from my defn: 1 - anything another thread does after is irrelevant 2 - undefined, just like other requests. 3 - no, usual rules apply since flush is not complete. Etc. :) Bill Sent from my Verizon Wireless 4G LTE DROID "Balaji, Pavan" <balaji(a)anl.gov> wrote: I can make slides to describe the options. I don't want to spend time making a standard-level document, since we are inevitably going to argue about and change. FWIW, the below definition is what I'd expect, but it still doesn't address the other questions in my list. -- Pavan > On Dec 12, 2014, at 3:40 PM, William Gropp <wgropp(a)illinois.edu> wrote: > > I’d like to see a document that describes the options, then arrange a telecon with the interested folks (I do find a well-prepared telecon useful). The telecon need not involve the entire WG. > > As a start, I’d define completing an “iflush” as completing RMA operations initiated before the iflush was called. It would say nothing (either way) about operations initiated after the iflush. Most of the answers should be derivable from this definition, which matches the other uses of nonblocking in MPI. > > Bill > > On Dec 11, 2014, at 11:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> Can we discuss this on the WG telecon (which the chair needs to restart)? >> >> I'd like to first put together rough thoughts on the semantics in slides before writing up text. Specific issues to clarify: >> >> 1. What happens when one thread is waiting on an iflush request while another thread keeps posting more operations. >> >> 2. What are the ordering semantics for two consecutive nonblocking iflush operations? Can they finish out of order? If they finish out of order, what are the semantics of accumulate operations with these epochs? Are they ordered? >> >> 3. What are the semantics of put operations in two nonblocking epochs? Can they overwrite each other? >> >> There might be more issues that need clarification too. I'm happy to make slides discussing a first draft of these (and more perhaps), but I don't want the discussion to be over email. >> >> -- Pavan >> >> Sent from my iPhone >> >>> On Dec 10, 2014, at 2:57 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> We really need a ticket i.e. a substantive written proposal for >>> iflush, etc. in order to make progress on the umbrella topic that >>> includes it and #459. >>> >>> Pavan: Please let me know when you will have something for this. >>> >>> Jeff >>> >>> >>> ---------- Forwarded message ---------- >>> From: MPI Forum <mpi-forum(a)lists.mpi-forum.org> >>> Date: Wed, Dec 10, 2014 at 11:11 AM >>> Subject: Re: [MPI Forum] #459: RMA sync ops with vector of windows >>> To: >>> >>> >>> #459: RMA sync ops with vector of windows >>> -------------------------------------+------------------------------------- >>> Reporter: jhammond | Owner: jhammond >>> Type: New routine(s) | Status: assigned >>> Priority: Not ready / author | Milestone: 2014/12/08 >>> rework | California, USA >>> Version: MPI 4.0 | Resolution: >>> Keywords: RMA | Implementation status: Waiting >>> -------------------------------------+------------------------------------- >>> >>> Comment (by gropp): >>> >>> The WG found this interesting, but notes that there are alternatives that >>> may provide the same capability. These include nonblocking flush. In a >>> straw vote, iflush received 11 votes and nflush received 3; in contrast, >>> nsync received 9 and isync received 4. >>> >>> -- >>> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/459#comment:3> >>> MPI Forum <https://svn.mpi-forum.org/> >>> MPI Forum >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> 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 -- 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