[mpich-discuss] Failed to allocate memory for an unexpected message

Luiz Carlos da Costa Junior lcjunior at ufrj.br
Fri Nov 1 16:30:34 CDT 2013


Hi Pavan,

Ok, I got the point about unexpected messages. I can modify the program
according to your note.
But things aren't clear enough for me yet.

You said:

You don’t need to know how many messages you will receive.  You only need
> to make sure that whenever a message comes in, it knows which buffer it
> should go into.  One way to fix that is to post N receives with ANY_SOURCE
> and ANY_TAG:


I understand that I will have to have N buffers, one for each posted
MPI_Irecv. I will also have to TEST (using MPI_PROBE or MPI_WAITANY) until
a message comes. The result of this test will identify which one of the
posted MPI_Irecv has actually received the message and then process the
right buffer. Is this correct?

Should I have to change anything at the sender's processes?

At the end, my receiver process receives a message identifying that it
should exit this routine. What should I do with the already posted
MPI_Irecv's? Can I cancel them?

Sorry for the newbie questions and thanks in advance for your attention.

Regards,
Luiz



On 31 October 2013 16:31, Pavan Balaji <balaji at mcs.anl.gov> wrote:

>
> On Oct 31, 2013, at 12:14 PM, Luiz Carlos da Costa Junior <
> lcjunior at ufrj.br> wrote:
> > I noticed that the numbers of 261895 or 261894 unexpected messages
> appear every time.
> > I am using AWS machine with 60GB of RAM memory to run my application. We
> could see during the execution that there was more than 30 GB available.
> > Is this a internal limitation of MPICH implementation? Would it be
> possible to recompile MPICH setting a different parameter?
> > Do you know where exactly this limitation occurs?
>
> Unexpected messages is a bad idea in general.  Even if it’s an internal
> parameter setting (which it isn’t), it’s not a good idea to just increase
> it.
>
> Can you modify your application to not have that many unexpected messages?
>  See my note on how you can post Irecvs to avoid this.
>
>   —- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
>
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20131101/98f42349/attachment.html>


More information about the discuss mailing list