On 10/30/2015 02:48 PM, Dave Love wrote:
Fabian Wein <fabian.w...@fau.de> writes:
Is this a valid test?
/opt/openmpi-1.10.0-gcc/bin/mpiexec -n 4 hostname
leo
leo
leo
leo
So, unless you turned off the default binding -- to socket? check the
mpirun man page -- it worked, but the "numa" level failed. I don't know
if that level has to exist, and there have been bugs in that area
before. Running lstopo might be useful, and checking that you're
picking up the right hwloc dynamic library.
Sorry, I don't understand. Where is hwloc dynamically linked? I made
now sure I
have only one type of libhwloc.so and libnuma.so on the system (there
were versions
of an older date). Is a a way to check the lib if it has the feature?
mpiexec only links libnuma which was actually the old version and is
now the one I
build from the numactl source by myself.
ldd /opt/openmpi-1.10.0-gcc/bin/mpiexec
linux-vdso.so.1 => (0x00007ffffdbaa000)
libopen-rte.so.12 => /opt/openmpi-1.10.0-gcc/lib/libopen-rte.so.12
(0x00007fbfdae58000)
libopen-pal.so.13 => /opt/openmpi-1.10.0-gcc/lib/libopen-pal.so.13
(0x00007fbfdab78000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fbfda958000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfda590000)
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1
(0x00007fbfda380000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbfda178000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbfd9f70000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fbfd9d68000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbfdb0d8000)
What happens if you try to bind to sockets, assuming you don't want to
bind to cores? [I don't understand why the default isn't to cores when
you have only one process per core.]
bind-to cpu and socket bring the same error as bind-to numa.
