<div dir="ltr"><div>Does anybody implement RMA and NBC requests differently from P2P ones such that this matters? How would an implementation support a different type of request for NBC+RMA than P2P? If an MPI_Request has to be a reference for P2P, how is it going to also support the not-a-reference case? I can imagine a union of P2P_Reference, RMA_Object_itself, and NBC_Object_itself, but seems like it would blow up the memory requirements for a vector of MPI_Requests if RMA_Object_itself or NBC_Object_itself are larger than 8 bytes.</div><div><br></div><div>I wonder if it is even a good idea to not maintain a reference to the request. In implementations that do not implement passive progress on everything, how does the progress engine know to poke an NBC request if there isn't an implementation of it in the queue?</div><div><br></div><div>Jeff</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 1:51 PM Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">IIRC, the argument for RMA was that we had not wanted to require the MPI library to maintain a reference to the request. There could be many RMA operations pending and the MPI library maintaining a list of pending operations could be a significant source of overhead. I seem to recall this having been the general sentiment at the time and it may have also applied to NBC.<div><br></div><div> ~Jim.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 8, 2020 at 7:15 PM Jeff Hammond via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">We should fix the RMA chapter with an erratum. I care less about NBC but share your ignorance of why it was done that way. <br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Aug 8, 2020, at 6:51 AM, Balaji, Pavan via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
Folks,
<div><br>
</div>
<div>Does someone remember why we disallowed users from calling MPI_Request_free on nonblocking collective requests? I remember the reasoning for not allowing cancel (i.e., the operation might have completed on some processes, but not all), but not
for Request_free. AFAICT, allowing the users to free the request doesn’t make any difference to the MPI library. The MPI library would simply maintain its own refcount to the request and continue forward till the operation completes. One of our users would
like to free NBC requests so they don’t have to wait for the operation to complete in some situations.</div>
<div><br>
</div>
<div>Unfortunately, when I added the Rput/Rget operations in the RMA chapter, I copy-pasted that text into RMA as well without thinking too hard about it. My bad! Either the RMA committee missed it too, or they thought of a reason that I can’t think
of now.</div>
<div><br>
</div>
<div>Can someone clarify or remind me what the reason was?</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div> — Pavan</div>
<div><br>
</div>
<div>MPI-3.1 standard, page 197, lines 26-27:</div>
<div><br>
</div>
<div>“<span style="font-size:11pt;font-family:CMR10">It is erroneous to call
</span><span style="font-size:11pt;font-family:CMSS10">MPI</span><span style="font-size:11pt;font-family:CMTT10">_</span><span style="font-size:11pt;font-family:CMSS10">REQUEST</span><span style="font-size:11pt;font-family:CMTT10">_</span><span style="font-size:11pt;font-family:CMSS10">FREE
</span><span style="font-size:11pt;font-family:CMR10">or </span><span style="font-size:11pt;font-family:CMSS10">MPI</span><span style="font-size:11pt;font-family:CMTT10">_</span><span style="font-size:11pt;font-family:CMSS10">CANCEL
</span><span style="font-size:11pt;font-family:CMR10">for a request associated with a nonblocking collective operation.</span>”</div>
<div><br>
</div>
<span>_______________________________________________</span><br><span>mpi-forum mailing list</span><br><span><a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a></span><br><span><a href="https://lists.mpi-forum.org/mailman/listinfo/mpi-forum" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpi-forum</a></span><br></div></blockquote></div>_______________________________________________<br>
mpi-forum mailing list<br>
<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpi-forum" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpi-forum</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div></div>