From your description, I don't see any reason why MPICH would hang if
the user code is correct.
Can you send us a small test code that reproduces this problem?
Halim
www.mcs.anl.gov/~aamer
On 11/3/17 10:27 AM, Adam Sylvester wrote:
> I have an application which runs 16 ranks, where there is a step in the
> processing where each rank does an MPI_Irecv() and MPI_Isend() with
> every other rank, then calls MPI_Waitall(). The code could likely be
> refactored to use an MPI_Alltoallv() instead, but that's not my point
> here as this portion of the code isn't a bottleneck.
>
> I've previously been using Open MPI which has run this block of code
> thousands of times without issues. I just switched over to MPICH 3.2
> (obviously recompiling my application) and it hangs in this block (there
> is MPI communication involving at least as much data movement earlier in
> the chain using a series of MPI_Ialltoallv() calls which completes
> without issue). I need to reduce the number of ranks down to 2 for it
> to make it through the MPI_recv() / MPI_Isend() / MPI_Waitall() section.
>
> I'm wondering if there's a setting for the max number of nonblocking
> messages that defaults to a low value for MPICH. Or any other thoughts
> on what I could be running into?
>
> Thanks.
> -Adam
>
>
> _______________________________________________
> discuss mailing list discuss(a)mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
>
_______________________________________________
discuss mailing list discuss(a)mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss
I have an application which runs 16 ranks, where there is a step in the
processing where each rank does an MPI_Irecv() and MPI_Isend() with every
other rank, then calls MPI_Waitall(). The code could likely be refactored
to use an MPI_Alltoallv() instead, but that's not my point here as this
portion of the code isn't a bottleneck.
I've previously been using Open MPI which has run this block of code
thousands of times without issues. I just switched over to MPICH 3.2
(obviously recompiling my application) and it hangs in this block (there is
MPI communication involving at least as much data movement earlier in the
chain using a series of MPI_Ialltoallv() calls which completes without
issue). I need to reduce the number of ranks down to 2 for it to make it
through the MPI_recv() / MPI_Isend() / MPI_Waitall() section.
I'm wondering if there's a setting for the max number of nonblocking
messages that defaults to a low value for MPICH. Or any other thoughts on
what I could be running into?
Thanks.
-Adam
_______________________________________________
discuss mailing list discuss(a)mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss
Thanks, Samuel. We are currently working heads-down on our 3.2.1 and 3.3b1 releases. But hwloc-2.0 is on our high-priority todo list. We'll hopefully get to it soon after SC.
-- Pavan
> On Oct 27, 2017, at 11:58 AM, Samuel Thibault <samuel.thibault(a)ens-lyon.org> wrote:
>
> Hello,
>
> hwloc 2 is to be released sooner or later, and it introduces a few API
> changes. The build log for version 3.3~a2 of mpich shows:
>
> tools/topo/hwloc/topo_hwloc.c:428:40: error: 'HWLOC_MEMBIND_REPLICATE' undeclared (first use in this function); did you mean 'HWLOC_MEMBIND_MIGRATE'?
> HYDT_topo_hwloc_info.membind = HWLOC_MEMBIND_REPLICATE;
> ^~~~~~~~~~~~~~~~~~~~~~~
> HWLOC_MEMBIND_MIGRATE
>
> There might also be other issues.
>
> To test against the development tree for hwloc 2, one can use
>
> git clone http://github.com/open-mpi/hwloc.git
>
> Samuel
>
> _______________________________________________
> discuss mailing list discuss(a)mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list discuss(a)mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss
