[Mpi3-ft] New RMA functions

[Pavan Balaji]

The new RMA proposal is an extension of the existing MPI-2.2 RMA 
interface; it'll all sit in the same chapter (please see Bill's slides 
at the last Forum for the details).

Two forms of RMA communication operations will be present:

1. The existing PUT/GET/ACCUMULATE operations which are from MPI-2.2. 
They will not take a request operand, and we want to retain it that way 
to minimize the performance overhead. Synchronization calls (such as 
closing an epoch or flush/flushall) wait for their completion, but they 
do not return a status object currently. Adding a status object to the 
synchronization calls is an option, though that'll require extensive 
changes. But adding them to the PUT/GET/ACCUMULATE operations themselves 
would beat the purpose of low-overhead communication, so that might not 
be doable.

2. The second set of operations is RPUT/RGET/RACCUMULATE, which take a 
request operand. For this part, I don't believe you'll have any issue 
with fault propagation, as you'd need to use WAIT/WAITALL/... to 
complete these requests. But remember that WAIT/WAITALL only complete 
these requests locally for these operations (i.e., you can reuse the 
buffer), while most synchronization operations complete the operations 
at the remote target.

Overall, if the user uses PUT/GET/ACCUMULATE, returning errors during 
synchronization calls only is OK, IMO. If the user wants error returns 
per operation, then he/she should use RPUT/RGET/RACCUMULATE. But it 
might still require the synchronization calls to return a status object.

Is this sufficient for you guys? I can bring it up at the next RMA 
telecon if needed.

Thanks,

  -- Pavan

On 02/24/2011 08:29 AM, Joshua Hursey wrote:
> Thanks for checking. I'm glad that the model we are pushing forward with regard to fault checking at synchronization points seems to work for the RMA folks.
>
> So I was thinking about adding an optional status object (rather than a request object) to put/get/accumulate operations that is filled in at the synchronization event. This is slightly different than the way we use status objects in other places in the standard, but I don't know if they need to be a full request. In particular, we want to provide the user with the option to disregard the parameter if they don't care about the specific operation which can be done with a MPI_STATUS_IGNORE, but there is no equivalent for requests. Since the synchronization operations are effectively waitall's on all requests posted during the epoch, we really only care about the status (and we want to avoid a conversation about canceling a one-sided request). What do you all think about that?
>
> So is this (status objects for put/get/accumulate) something that they have already put in the RMA proposal, or just something they would be open to adding?
>
> As I mentioned on the call, I am hesitant to change the one-sided interfaces currently in the standard to add the status object since the new RMA functionality is bring brought forward. Is the intention of the new RMA proposal to replace the current one-sided chapter, or to sit beside it? If the latter, then we may want to consider a smaller proposal just to add the status object to the one-sided operations. If the former, then we can just wait for the new semantics.
>
> Thanks,
> Josh
>
> On Feb 23, 2011, at 2:43 PM, Darius Buntinas wrote:
>
>>
>> After today's concall, I talked to Pavan about fault-tolerance and the new RMA functions.  He said that it would be appropriate to check for/report errors at synchronization points (like the end of epochs and things like flush), and for operations that take requests (like puts with requests).
>>
>> This sounds like what was suggested during the call.
>>
>> -d
>> _______________________________________________
>> mpi3-ft mailing list
>> mpi3-ft at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>>
>
> ------------------------------------
> Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> http://users.nccs.gov/~jjhursey
>
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji