[mpiwg-rma] Changes to the RMA chapter

Jeff Hammond jeff.science at gmail.com
Thu Mar 5 12:12:58 CST 2015


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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.mpi-forum.org
>> >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>> >>>>
>> >>>> _______________________________________________
>> >>>> mpiwg-rma mailing list
>> >>>> mpiwg-rma at 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 at lists.mpi-forum.org
>> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>> >>
>> >> _______________________________________________
>> >> mpiwg-rma mailing list
>> >> mpiwg-rma at 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 at lists.mpi-forum.org
>> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>>
>> _______________________________________________
>> mpiwg-rma mailing list
>> mpiwg-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/



More information about the mpiwg-rma mailing list