Jeff - I think it is different from a standards point of view, and has been different for some implementations. Take the Portals 3 implementation on Red Storm; the implementation did not allocate memory internally after MPI_INIT. So there was never a point at which the implementation would receive a message and try to allocate memory to land it. The user might be faced with that decision, but she can also free other user memory to make space for the incoming message before posting the receive. So I think it is, semantically, different. That being said, I don't think resource exhaustion corner cases are a deal breaker for me. I think some implementation-dependent phrasing might be acceptable. It might be useful to define the message transmission/matching semantics for these corner cases. For example, if MPI_Arecv returns an error because of resource exhaustion, is the message lost (my preference) or left in the receive queue? If the message is lost, what happens to the sender if the send was a synchronous send? Brian On 8/26/13 9:54 AM, "Jeff Squyres (jsquyres)" <[email protected]> wrote:

FWIW, I'm not really sure I see how the failure for MPI_ARECV to get a buffer (via malloc or whatever mechanism it wants) is substantially different than failing to get a buffer for any incoming message.

Indeed, for ARECV, an implementation may well try to use a freelist to allocate a buffer, or fully-lazily allocate a buffer (because it won't know the size until the message is received). Meaning that the allocation will (potentially) occur on the same/similar path as all receive messages.

Put that together with the fact that normal receives can also fail to get an eager or unexpected buffer when a new message arrives, for example.

Therefore the error handling could well be the same between the ARECV and "regular" receive cases.

On Aug 26, 2013, at 11:27 AM, Pavan Balaji <[email protected]> wrote:

...

Can you clarify a bit more?

Is that a fatal failure at that point? Or is it more like MPI_Alloc_mem failing where I can retry later or just do a regular malloc (in this case, a regular MPI_RECV).

-- Pavan

On 08/26/2013 10:19 AM, David Goodell (dgoodell) wrote:

...

I'd say that's implementation defined behavior, no different than hitting any other system resource limitation right now.

-Dave

On Aug 26, 2013, at 10:14 AM, Pavan Balaji <[email protected]> wrote:

...

Jeff,

This should probably be moved to the point-to-point WG, but I'll comment on this thread for now.

Such a proposal was brought up at the very early stage of the MPI-2.1 process (I don't remember by whom). The main concern at that point was what happens when the memory allocation fails. Will the receive fail? What happens to the sent message?

Can you work these details into your slides?

-- Pavan

On 08/26/2013 10:10 AM, Jeff Squyres (jsquyres) wrote:

...

Dave Goodell and I have a proposal that we've socialized a bit around with other Forum members, and would now like larger Forum feedback. I'll be presenting the attached slides on the concept of an "allocate receive" in Madrid (3:30-4pm on Thursday).

There's no text or ticket yet; this is an idea that we want to get feedback on before working up a full proposal.

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories