Only check the if the Fortran compiler needs additional CLI flags for
preprocessing .F90 files if we actually have an F90 compiler.
Also fix a the AC_MSG_* usage.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
This bullet can be removed since SunCC is no longer supported as of
version 5.0.0.
Signed-off-by: Paul Kefer <24892969+paulkefer@users.noreply.github.com>
Found a handful of other URLs that weren't https-ized, so I updated
them, too (after verifying that they support https, of course).
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
This reverts commit 1aabbe456d.
Update PMIx and PRRTE, plus PRRTE config integration
Cleanup how we pass the extra libs and LDFLAGS for linking against
external libevent, hwloc, and pmix installs.
Catch the flag indicating that PMIx provided the user-level default MCA
params so we don't go looking for them ourselves.
Cleanup misc config warnings
Signed-off-by: Ralph Castain <rhc@pmix.org>
PRRTE needs hwloc and libevent, so it needs to be setup "late" in
configure.ac. However, we don't want to do it at the absolute bottom
of configure.ac, because right near the bottom, we setup CPPFLAGS (and
others) with values that are expected to be used only in
Makefile[.am]'s -- i.e., "$(foo)" values. Such values are not able to
be used here in configure.
Hence, move the PRRTE setup up above where we do these "final"/
only-relevant-to-Makefile[.am] CPPFLAGS (etc.) updates occur.
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
.F90 files are preprocessed by gfortran and other compilers.
NAG compilers only preprocess .{ff,ff90,ff95} files, and the -fpp
flag is required to process .F90 files.
Fixesopen-mpi/ompi#7583
Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
libevent, hwloc, and pmix can be external and may require that their
libs be explicitly linked into the PRRTE binaries
Signed-off-by: Ralph Castain <rhc@pmix.org>
Properly mark/detect that a daemon sourced the event broadcast to avoid
reinjecting it into the PMIx server library. Correct the source field
for the event notify call on launcher ready.
Update event notification for tool support
Deal with a variety of race conditions related to tool reconnection to a
different server.
Signed-off-by: Ralph Castain <rhc@pmix.org>
Pass the correct ompi_proc_t and array length to
mca_pml_base_pml_check_selected() during dynamic modex.
Signed-off-by: Yossi Itigin <yosefe@mellanox.com>
To suppress Valgrind warnings, opal_tsd_keys_destruct() needs to explicitly
release TSD values of the main thread. However, they were not freed if keys are
created by non-main threads. This patch fixes it.
This patch also optimizes allocation of opal_tsd_key_values by doubling its size
when count >= length instead of increasing the size by one.
Signed-off-by: Shintaro Iwasaki <siwasaki@anl.gov>
Add a framework to support different types of threading models including
user space thread packages such as Qthreads and argobot:
https://github.com/pmodels/argobotshttps://github.com/Qthreads/qthreads
The default threading model is pthreads. Alternate thread models are
specificed at configure time using the --with-threads=X option.
The framework is static. The theading model to use is selected at
Open MPI configure/build time.
mca/threads: implement Argobots threading layer
config: fix thread configury
- Add double quotations
- Change Argobot to Argobots
config: implement Argobots check
If the poll time is too long, MPI hangs.
This quick fix just sets it to 0, but it is not good for the
Pthreads version. Need to find a good way to abstract it.
Note that even 1 (= 1 millisecond) causes disastrous performance
degradation.
rework threads MCA framework configury
It now works more like the ompi/mca/rte configury,
modulo some edge items that are special for threading package
linking, etc.
qthreads module
some argobots cleanup
Signed-off-by: Noah Evans <noah.evans@gmail.com>
Signed-off-by: Shintaro Iwasaki <siwasaki@anl.gov>
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
Change ompi_mtl_ofi_get_endpoint() to call the active PML's
add_procs() rather than the OFI MTL add_procs() directly when
discovering a new process during operation.
Functionally, this has no impact in correct operation. However,
the current behavior means that the heterogenous and active PML
checks are not being executed in the dynamic discovery case.
Signed-off-by: Brian Barrett <bbarrett@amazon.com>
Deprecate --am and --amca options
Avoid default param files on backend nodes
Any parameters in the PRRTE default or user param files will have been
picked up by prte and included in the environment sent to the prted, so
don't open those files on the backend.
Avoid picking up MCA param file info on backend
Avoid the scaling problem at PRRTE startup by only reading the system
and user param files on the frontend.
Complete revisions to cmd line parser for OMPI
Per specification, enforce following precedence order:
1. system-level default parameter file
1. user-level default parameter file
1. Anything found in the environment
1. "--tune" files. Note that "--amca" goes away and becomes equivalent to "--tune". Okay if it is provided more than once on a cmd line (we will aggregate the list of files, retaining order), but an error if a parameter is referenced in more than one file with a different value
1. "--mca" options. Again, error if the same option appears more than once with a different value. Allowed to override a parameter referenced in a "tune" file
1. "-x" options. Allowed to overwrite options given in a "tune" file, but cannot conflict with an explicit "--mca" option
1. all other options
Fix special handling of "-np"
Get agreement on jobid across the layers
Need all three pieces (PRRTE, PMIx, and OPAL) to agree on the nspace
conversion to jobid method
Ensure prte show_help messages get output
Print abnormal termination messages
Cleanup error reporting in persistent operations
Signed-off-by: Ralph Castain <rhc@pmix.org>
dd
Signed-off-by: Ralph Castain <rhc@pmix.org>
Clarify exactly what compiler atomics support is needed to build Open
MPI.
For example, the following configuration now fails to configure on
Solaris:
- Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31
- Also tried with GCC 4.0.2
with the following error:
configure: error: No atomic primitives available for sparc-sun-solaris2.11
Thanks to @jdelsign for the report.
Signed-off-by: Ralph Castain <rhc@pmix.org>
Signed-off-by: Jeff Squyres <jsquyres@cisco.com>
We currently save the hostname of a proc when we create the ompi_proc_t for it. This was originally done because the only method we had for discovering the host of a proc was to include that info in the modex, and we had to therefore store it somewhere proc-local. Obviously, this ccarried a memory penalty for storing all those strings, and so we added a "cutoff" parameter so that we wouldn't collect hostnames above a certain number of procs.
Unfortunately, this still results in an 8-byte/proc memory cost as we have a char* pointer in the opal_proc_t that is contained in the ompi_proc_t so that we can store the hostname of the other procs if we fall below the cutoff. At scale, this can consume a fair amount of memory.
With the switch to relying on PMIx, there is no longer a need to cache the proc hostnames. Using the "optional" feature of PMIx_Get, we restrict the retrieval to be purely proc-local - i.e., we retrieve the info either via shared memory or from within the proc-internal hash storage (depending upon the active PMIx components). Thus, the retrieval of a hostname is purely a local operation involving no communication.
All RM's are required to provide a complete hostname map of all procs at startup. Thus, we have full access to all hostnames without including them in a modex or having to cache them on each proc. This allows us to remove the char* pointer from the opal_proc_t, saving us 8-bytes/proc.
Unfortunately, PMIx_Get does not currently support the return of a static pointer to memory. Thus, even though PMIx has the hostname in its memory, it can only return a malloc'd version of it. I have therefore ensured that the return from opal_get_proc_hostname is consistently malloc'd and free'd wherever used. This shouldn't be a burden as the hostname is only used in one of two circumstances:
(a) in an error message
(b) in a verbose output for debugging purposes
Thus, there should be no performance penalty associated with the malloc/free requirement. PMIx will eventually be returning static pointers, and so we can eventually simplify this method and return a "const char*" - but as noted, this really isn't an issue even today.
Signed-off-by: Ralph Castain <rhc@pmix.org>
OMPI can only support PMIx v3 and above. PRRTE requires at least PMIx
v4, so protect against the case where OMPI is built against an external
PMIx v3.
Fix check of PMIx_Init return code for singleton operations.
Ensure that the PMIx framework gets properly opened.
Signed-off-by: Ralph Castain <rhc@pmix.org>
