[mpiwg-rma] RMA WG discussion 12/2014

[Jeff Hammond]

I don't know what RMA users other than I will expect. But advice to users might be useful to, you know, advise users as to what reasonable expectations are :-)

Jeff

Sent from my iPhone

> On Nov 12, 2014, at 12:59 PM, Jim Dinan <james.dinan at gmail.com> wrote:
> 
> So, users won't expect that the interface can remotely complete a small RMA operation such that it overtakes a previously issued large RMA operation?
> 
>> On Tue, Nov 11, 2014 at 2:02 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
>> It seems only obvious that remote request completion only makes sense
>> for large messages where individual completion makes sense.  I can
>> think of numerous contexts where it does, especially in the limit of
>> not being able to register an infinity of pages.
>> 
>> Jeff
>> 
>> On Tue, Nov 11, 2014 at 5:49 PM, Jim Dinan <james.dinan at gmail.com> wrote:
>> > I think the argument against was that can be hard to get fine-grain,
>> > per-operation remote completion, and harder still to do it efficiently.  So,
>> > we could end up with an interface that builds a false expectation where
>> > users expect overlap that many implementations can't provide.
>> >
>> >  ~Jim.
>> >
>> > On Thu, Nov 6, 2014 at 2:38 AM, Jeff Hammond <jeff.science at gmail.com> wrote:
>> >>
>> >> Barrett didn't have a good argument against these functions except
>> >> argument count, as I recall. There was some debate as to whether nonblocking
>> >> flush was better, albeit in an apples-to-oranges way.
>> >>
>> >> I think most people are just frustrated with the grossness of the corner
>> >> we are painted into with RMA API. Pirate RMA is the natural consequence of
>> >> past decisions. The other solution to the application's problem is
>> >> overlapping windows, which would be only mildly awful if not for our
>> >> inability to support just one memory model.
>> >>
>> >> Jeff
>> >>
>> >> Sent from my iPhone
>> >>
>> >> > On Nov 6, 2014, at 6:47 AM, "Underwood, Keith D"
>> >> > <keith.d.underwood at intel.com> wrote:
>> >> >
>> >> > So, what, you're telling me I have to start attending again to give you
>> >> > an appropriate amount of difficulty for some of these proposals?
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: mpiwg-rma [mailto:mpiwg-rma-bounces at lists.mpi-forum.org] On
>> >> >> Behalf Of Jeff Hammond
>> >> >> Sent: Tuesday, November 04, 2014 12:39 PM
>> >> >> To: MPI WG Remote Memory Access working group
>> >> >> Subject: Re: [mpiwg-rma] RMA WG discussion 12/2014
>> >> >>
>> >> >> Pirate RMA (remote request completion - cannot remember ticket number)
>> >> >> needs to be retired if WG is still not in favor. But then again,
>> >> >> Barrett is gone :-
>> >> >> )
>> >> >>
>> >> >> Nonblocking RMA epochs in your SC14 paper should be discussed. That
>> >> >> looks
>> >> >> promising. Can you create a ticket for it?
>> >> >>
>> >> >> Jeff
>> >> >>
>> >> >> Sent from my iPhone
>> >> >>
>> >> >>> On Nov 4, 2014, at 5:48 PM, William Gropp <wgropp at illinois.edu> wrote:
>> >> >>>
>> >> >>> The wiki page already has 397 and I added 460.  Note also that there
>> >> >>> is a list
>> >> >> of open tickets on that page; we should try to either adopt or retire
>> >> >> the open
>> >> >> ones.
>> >> >>>
>> >> >>> Bill
>> >> >>>
>> >> >>>> On Nov 4, 2014, at 10:32 AM, Jeff Hammond <jeff.science at gmail.com>
>> >> >> wrote:
>> >> >>>>
>> >> >>>> I would like to discuss
>> >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 and the
>> >> >>>> closely related
>> >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/460 in San Jose.
>> >> >>>>
>> >> >>>> Can we collect the other tickets of interest to people and ask Martin
>> >> >>>> for the appropriate allocation of time?
>> >> >>>>
>> >> >>>> Thanks,
>> >> >>>>
>> >> >>>> Jeff
>> >> >>>>
>> >> >>>> --
>> >> >>>> Jeff Hammond
>> >> >>>> jeff.science at gmail.com
>> >> >>>> http://jeffhammond.github.io/
>> >> >>>> _______________________________________________
>> >> >>>> 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
>> >> > _______________________________________________
>> >> > 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/
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20141112/0ee90a02/attachment-0001.html>