mpirun: add cli option to turn off gpu support #51
Conversation
|
@edgargabriel check wording in the rstxt file and suggest changes. I'll open a small docs related commit on ompi as well. |
|
Errr...few things: (a) there is no "disable gpu support" defined in PMIx - I assume you are planning something over there? (b) What are you expecting PMIx to do with this? I don't see PRRTE doing anything. Are we just setting an envar (MCA or otherwise)? (c) why would you put it here, and then include a change to the PRRTE schizo component??? |
|
that was me looking at your stuff too much. i was following the mem kind thing example that you did. what does pmix have to do with memkind support? seems same question applied there. |
idea is that maybe one might want to build open mpi with gpu support, but there may be performance benefit of disabling all gpu related paths when using this library on systems without accelerators. Signed-off-by: Howard Pritchard <[email protected]>
hppritcha
force-pushed
the
big_gpu_switch
branch
from
771fed4 to
7ef15a1
Compare
Sigh - that isn't what I said. I asked what you were expecting PMIx to do with it - pass an envar, add it to the job-level info, ...? It was a simple question. We knew the answer for memkind - just wanted to hear an answer for this one. There are several ways one can deal with these things. Setting an envar is one - another is adding it to the job-level info. The first doesn't require a PMIx key, while the second does. Envars can be a bad way to pass things, while job-level info tends to be more reliable. Sometimes, you just need to stop and think thru the various use-cases (e.g., will this be an inherited characteristic across comm-spawn? Will a tool need to determine the status of this for a given job, or include it in a launch request?) before focusing down on a solution. |
|
Please take a look at openpmix/openpmix#3528 and openpmix#2134 to get a better understanding of what I was trying to communicate. See if that does what you were after. |
|
FWIW: I committed the upstream changes as (a) they were of potential interest to another library group, and (b) the tools folks indicated interest in querying the state of GPU support. |
idea is that maybe one might want to build open mpi with gpu support, but there may be performance benefit of disabling all gpu related paths when using this library on systems without accelerators.