<div dir="ltr"><div style>Brian,</div><div style><br></div><div style>Can you elaborate on the source of performance loss from operations between Iflush and its completion?</div><div style><br></div><div style>Jeff,</div><div style>
<br></div><div style>I think the pirate RMA (separate per operation local/remote completion) idea is good. I'm not sure I'm sold on the interface; I'd rather not add so many new functions, if there's some other way we could do it. I think we should explore the different design options so that we can verify for the Forum that we've chosen the best one.</div>
<div style><br></div><div style>All,</div><div style><br></div><div style>Shall we schedule an RMA WG meeting some time soon? Seems like it would be good to get high bandwidth to go over these changes. I also should give the WG and update on the MPI_Aint_add session from the last Forum meeting.</div>
<div style><br></div><div style> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 6:06 PM, Pavan Balaji <span dir="ltr"><<a href="mailto:balaji@mcs.anl.gov" target="_blank">balaji@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
That's a fair point and I agree with it. We should not add overhead to existing functionality to support this. I guess the thought here is that for implementations that support fully asynchronous RMA communication, test or wait can essentially do the flush, with the caveat that test cannot block if someone else is holding the lock.<br>
<div class="im HOEnZb"><br>
--<br>
Pavan Balaji<br>
<a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
<br>
</div><div class="im HOEnZb">"Barrett, Brian W" <<a href="mailto:bwbarre@sandia.gov">bwbarre@sandia.gov</a>> wrote:<br>
<br>
As an FYI, my problem with this proposal is two-fold:<br>
<br>
First, we need to deal with the fact that many of the calls are local today, meaning we need to fix some definitions, which is a big change (iflush/flush shouldn't have the same semantics).<br>
<br>
Second, the semantics of iflush (and friends) need lots of care. For example, allowing a communication event between iflush and wait would greatly hinder my implementation's performance when not using iflush.<br>
<br>
I understand the desire and like many of the non-blocking, but there are many places that we should balance non-blocking variants vs. performance loss...<br>
<br>
Brian<br>
<br>
<br>
<br>
Sent with Good (<a href="http://www.good.com" target="_blank">www.good.com</a>)<br>
<br>
<br>
-----Original Message-----<br>
</div><div class="HOEnZb"><div class="h5">From: Pavan Balaji [<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a><mailto:<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a>>]<br>
Sent: Friday, June 14, 2013 02:51 PM Mountain Standard Time<br>
To: <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
Subject: [EXTERNAL] Re: [Mpi3-rma] request-based ops<br>
<br>
<br>
<br>
On 06/14/2013 03:43 PM, Jim Dinan wrote:<br>
> Ahh, right, I had to miss that session at the Forum meeting. If anyone<br>
> else is looking for them, these are the slides:<br>
><br>
> <a href="http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf" target="_blank">http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf</a><br>
><br>
> I was indeed forgetting about remote versus local completion and polling<br>
> on the request. It sounds like this would definitely fill a gap in the<br>
> RMA interface.<br>
<br>
FYI, this was not meant to be an RMA proposal, since it touches blocking<br>
function calls in many chapters (e.g., COMM_ICONNECT and COMM_IACCEPT).<br>
<br>
I think I/O operations have a similar ticket as well.<br>
<br>
All these tickets need to be combined into a single nonblocking<br>
operations ticket.<br>
<br>
-- Pavan<br>
<br>
--<br>
Pavan Balaji<br>
<a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
</div></div></blockquote></div><br></div>