Gilles Gouaillardet, on ven. 21 juil. 2017 10:57:36 +0900, wrote:
> if you are fine with using more memory, and your application should not
> generate too much unexpected messages, then you can bump the eager_limit
> for example
>
> mpirun --mca btl_tcp_eager_limit $((8*1024*1024+128)) ...
Thanks
Hello,
George Bosilca, on jeu. 20 juil. 2017 19:05:34 -0500, wrote:
> Can you reproduce the same behavior after the first batch of messages ?
Yes, putting a loop around the whole series of communications, event
with a 1-second pause in between, gets the same behavior repeated.
> Assuming the tim
Sam,
this example is using 8 MB size messages
if you are fine with using more memory, and your application should not
generate too much unexpected messages, then you can bump the eager_limit
for example
mpirun --mca btl_tcp_eager_limit $((8*1024*1024+128)) ...
worked for me
George,
in ma
Sam,
Open MPI aggregates messages only when network constraints prevent the
messages from being timely delivered. In this particular case I think that
our delayed business card exchange and connection setup is delaying the
delivery of the first batch of messages (and the BTL will aggregate them
wh
Hello,
We are getting a strong performance issue, which is due to a missing
pipelining behavior from OpenMPI when running over TCP. I have attached
a test case. Basically what it does is
if (myrank == 0) {
for (i = 0; i < N; i++)
MPI_Isend(...);
} else {
for (i = 0
I see... Now it all makes sense. Since Cpus_allowed(_list) shows the effective
CPU mask, I expected Mems_allowed(_list) would do the same.
Thanks for the clarification.
Cheers,
Hristo
-Original Message-
From: users [mailto:users-boun...@lists.open-mpi.org] On Behalf Of Brice Goglin
Sent
Hello
Mems_allowed_list is what your current cgroup/cpuset allows. It is
different from what mbind/numactl/hwloc/... change.
The former is a root-only restriction that cannot be ignored by
processes placed in that cgroup.
The latter is a user-changeable binding that must be inside the former.
Bri
