Max,
Thanks for the report and suggesting a solution!
Could you please issue a pull request so your fix can be reviewed?
note the commit has to be signed-off (IANAL, make sure you understand
the implications)
in order to be accepted upstream.
Cheers,
Gilles
On Thu, Feb 4, 2021 at 6:40 AM Max
I have updated the site to reflect this discussion to-date. I'm still trying to
figure out what to do about low-level libs. For now, I've removed the envars
and modified suggestions.
https://openpmix.github.io/support/faq/avoid-hwloc-dup
Further comment/input is welcome.
> On Feb 3, 2021, at
Hi everyone,
I recently opened an issue on github, before reading on the OpenMPI site
that I should have posted my problem here, sorry.
I get a segmentation fault when using one sided communication on a
new communicator created by MPI_Comm_split.
All the details are on github :
What if we do this:
- if you are using PMIx v4.1 or above, then there is no problem. Call
PMIx_Load_topology and we will always return a valid pointer to the topology,
subject to the caveat that all members of the process (as well as the server)
must use the same hwloc version.
- if you are
I guess this begs the question: how does a library detect that the shmem region
has already been mapped? If we attempt to map it and fail, does that mean it
has already been mapped or that it doesn't exist?
It isn't reasonable to expect that all the libraries in a process will
coordinate such
We discussed this on the OMPI teleconf this week. Geoff has some notes from the
meeting, but I don't think they are posted yet. I updated the issue with my
notes - please let me know if I missed anything.
https://github.com/open-mpi/ompi/issues/7486#issuecomment-772589937
Thanks!
On Mon,
Hello Ralph
One thing that isn't clear in this document : the hwloc shmem region may
only be mapped *once* per process (because the mmap address is always
the same). Hence, if a library calls adopt() in the process, others will
fail. This applies to the 2nd and 3rd case in "Accessing the HWLOC
