* Removes support for big endian PPC
* Removes support for XL compiler older than 13.1
* Fixes Issue #4053
Signed-off-by: Joshua Hursey <jhursey@us.ibm.com>
Someone posted an MTT test where libmpi_usempi_ignore_tkr.so ended
up with symbols like these being identifed as errors:
[error] MPI
[error] _Cmpi_fortran_status_ignore
[error] _Cmpi_fortran_statuses_ignore
those must be compiler-generated names so we shouldn't identify them
as problematic.
Signed-off-by: Mark Allen <markalle@us.ibm.com>
- change the increment used to test various no. of aggregators
to avoid using only power of two numbers
- convert some paratemers in the cost function from integers to
to floats for providing smoother and more consistent results
- set the FVIEW_IS_SET flag on the file *only* if the user
has set anything else than the default file view.
Signed-off-by: Edgar Gabriel <gabriel@cs.uh.edu>
adjust how the aggregator nodes are selected depending on whether processes
have been mapped by node or anything else.
Signed-off-by: Edgar Gabriel <gabriel@cs.uh.edu>
Check for the binding policy used. We are only interested in
whether mapby-node has been set right now (could be extended later)
and only on MPI_COMM_WORLD, since for all other sub-communicators
it is virtually impossible to identify their layout across nodes
in the most generic sense. This is used by OMPIO for deciding which
ranks to use for aggregators
Signed-off-by: Edgar Gabriel <gabriel@cs.uh.edu>
add a new aggregator selection algorithm based on the performance
model described in:
Shweta Jha, Edgar Gabriel,
'Performance Models for Communication in Collective I/O Operations'
Proceedings of the 17th IEEE/ACM Symposium
on Cluster, Cloud and Grid Computing, Workshop on Theoretical
Approaches to Performance Evaluation, Modeling and Simulation, 2017.
Signed-off-by: Edgar Gabriel <gabriel@cs.uh.edu>
This module was always intended to be a proof of concept, and was far
from complete. If/when someone implemented F08 descriptor support for
the mpi_f08 module, this commit can either be restored or used as
reference material.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
in order to solve an egg and the chicken problem, in which mpiext need mpi-f08-types.mod
and/but use-mpi-f08[-desc] needs mpiext, add an extra step
- build fortran 2008 modules only
- build fortran 2008 mpi extensions
- and then build fortran 2008 bindings
Fixesopen-mpi/ompi#3605
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
Turns out that supplying NULL to group_register in the
mca_base_var_group_component_register is not a good
idea if one wants for ompi_info to work as intended.
The ugni and vader btl's both call this before
registering component variables. This borks up
the ompi_info works since NULL is supplied as the project
name. So, now supply the project name rather than
just NULL to group register.
Fixes#4020.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
usnic endpoints was always created with default send credit value of 8. This
commit assign the correct number from the hardware instead.
Signed-off-by: Thananon Patinyasakdikul <apatinya@cisco.com>
It is not possible to use the patcher based memory hooks without
hooking madvise (MADV_DONTNEED). This commit updates the patcher
memory hooks to always hook madvise. This should be safe with recent
rcache updates.
References #3685. Close when merged into v2.0.x, v2.x, and v3.0.x.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
The current VMA cache implementation backing rcache/grdma can run into
a deadlock situation in multi-threaded code when madvise is hooked and
the c library uses locks. In this case we may run into the following
situation:
Thread 1:
...
free () <- Holding libc lock
madvice_hook ()
vma_iteration () <- Blocked waiting for vma lock
Thread 2:
...
vma_insert () <- Holding vma lock
vma_item_new ()
malloc () <- Blocked waiting for libc lock
To fix this problem we chose to remove the madvise () hook but that
fix is causing issue #3685. This commit aims to greatly reduce the
chance that the deadlock will be hit by putting vma items into a free
list. This moves the allocation outside the vma lock. In general there
are a relatively small number of vma items so the default is to
allocate 2048 vma items. This default is configurable but it is likely
the number is too large not too small.
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
