Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mpirun: add cli option to turn off gpu support #51

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hppritcha
Copy link
Member

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.

@hppritcha
Copy link
Member Author

@edgargabriel check wording in the rstxt file and suggest changes. I'll open a small docs related commit on ompi as well.

@rhc54
Copy link

rhc54 commented Feb 5, 2025

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???

@hppritcha
Copy link
Member Author

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]>
@rhc54
Copy link

rhc54 commented Feb 5, 2025

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.

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.

@rhc54
Copy link

rhc54 commented Feb 6, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants