[mpich-discuss] MPI_Comm_spawn crosses node boundaries
Mccall, Kurt E. (MSFC-EV41)
kurt.e.mccall at nasa.gov
Fri Jan 28 14:22:02 CST 2022
Ken,
I confirmed that MPI_Comm_spawn fails completely if I build MPICH without the PMI2 option. Looking at the Slurm documentation https://slurm.schedmd.com/mpi_guide.html#intel_mpiexec_hydra
it states "All MPI_comm_spawn work fine now going through hydra's PMI 1.1 interface." The full quote is below for reference.
1) how do I build MPICH to support hydra's PMI 1.1 interface?
2) Can you offer any guesses on how to build Slurm to do the same? (I realize this isn't a Slurm forum 😊)
Thanks,
Kurt
=========== Full quote ===============
MPICH2 with mpiexec
Do not add any flags to mpich and build the default (e.g. "./configure -prefix ... ". Do NOT pass the --with-slurm, --with-pmi, --enable-pmiport options).
Do not add -lpmi to your application (it will force slurm's pmi 1 interface which doesn't support PMI_Spawn_multiple).
Launch the application using salloc to create the job allocation and mpiexec to launch the tasks. A simple example is shown below.
salloc -N 2 mpiexec my_application
All MPI_comm_spawn work fine now going through hydra's PMI 1.1 interface.
-----Original Message-----
From: Mccall, Kurt E. (MSFC-EV41) via discuss <discuss at mpich.org>
Sent: Friday, January 28, 2022 1:43 PM
To: Raffenetti, Ken <raffenet at anl.gov>; discuss at mpich.org
Cc: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov>
Subject: [EXTERNAL] Re: [mpich-discuss] MPI_Comm_spawn crosses node boundaries
I have built in the past without the pmi2 option, and MPI_Comm_spawn doesn't work at all. My memory is a little fuzzy, so I'll try that to make sure. In the meantime, can you recommend an option with which to build Slurm that MPICH also supports and has tested? Here is what we have now:
$ srun --mpi=list
srun: MPI types are...
srun: cray_shasta
srun: pmi2
srun: none
-----Original Message-----
From: Raffenetti, Ken <raffenet at anl.gov<mailto:raffenet at anl.gov>>
Sent: Friday, January 28, 2022 1:35 PM
To: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>>; discuss at mpich.org<mailto:discuss at mpich.org>
Subject: [EXTERNAL] Re: [mpich-discuss] MPI_Comm_spawn crosses node boundaries
I'm just now realizing that we don't test spawn functionality with our pmi2 implementation. Can you try rebuilding without that option and see if it works as expected?
Ken
On 1/28/22, 1:18 PM, "Mccall, Kurt E. (MSFC-EV41)" <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>> wrote:
../mpich-4.0rc3/configure --prefix=/opt/mpich --with-pmi=pmi2/simple --with-device=ch3:nemesis --disable-fortran -enable-debuginfo --enable-g=debug
-----Original Message-----
From: Raffenetti, Ken <raffenet at anl.gov<mailto:raffenet at anl.gov>>
Sent: Friday, January 28, 2022 1:16 PM
To: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>>; discuss at mpich.org<mailto:discuss at mpich.org>
Subject: [EXTERNAL] Re: [mpich-discuss] MPI_Comm_spawn crosses node boundaries
From what I can tell, the info keyvals are not being sent to the process manager, which would explain what you are seeing. Need to investigate why that is happening next. What is your MPICH ./configure line? That'll help narrow where to look.
Ken
On 1/28/22, 12:49 PM, "Mccall, Kurt E. (MSFC-EV41)" <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>> wrote:
Ken,
There is a lot of my own output mixed up in the "mpiexec -v" output. I hope you can make sense of this.
Thanks,
Kurt
-----Original Message-----
From: Raffenetti, Ken <raffenet at anl.gov<mailto:raffenet at anl.gov>>
Sent: Friday, January 28, 2022 12:36 PM
To: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>>; discuss at mpich.org<mailto:discuss at mpich.org>
Subject: [EXTERNAL] Re: [mpich-discuss] MPI_Comm_spawn crosses node boundaries
"ip_address" won't be recognized, only "host", "hosts", or "hostfile". Could you run an example using "mpiexec -v" and capture/share the output? That should help tell us if the hostname information is being fed correctly to the process manager by the spawn command.
Ken
On 1/28/22, 11:35 AM, "Mccall, Kurt E. (MSFC-EV41)" <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>> wrote:
Ken,
I'm using sbatch, which calls a bash script that calls mpiexec (4.0rc3). Which host name convention is correct, the short or the long host name? Would the "ip_address" info key work?
Kurt
-----Original Message-----
From: Raffenetti, Ken <raffenet at anl.gov<mailto:raffenet at anl.gov>>
Sent: Friday, January 28, 2022 10:49 AM
To: discuss at mpich.org<mailto:discuss at mpich.org>
Cc: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall at nasa.gov<mailto:kurt.e.mccall at nasa.gov>>
Subject: [EXTERNAL] Re: [mpich-discuss] MPI_Comm_spawn crosses node boundaries
Are you using mpiexec or srun when initially launching your job? Hydra (mpiexec) should support the "host" info key, but I'm not sure if srun will.
Ken
On 1/28/22, 10:41 AM, "Mccall, Kurt E. (MSFC-EV41) via discuss" <discuss at mpich.org<mailto:discuss at mpich.org>> wrote:
Hi,
Running MPICH under Slurm, MPI_Comm_spawn unexpectedly creates new processes on any and all of the nodes that Slurm allocates to the job. I would like it to only create new processes locally on the node that called MPI_Comm_spawn.
I’ve tried passing MPI_Comm_spawn an info struct created like this:
MPI_Info info;
MPI_Info_create(&info);
MPI_Info_set(info, "host", host_name);
MPI_Info_set(info, "bind_to", "core");
where hostname = “n001” or even the full name “n001.cluster.pssclabs.com”
but that doesn’t prevent the problem. Any suggestions?
Thanks,
Kurt
_______________________________________________
discuss mailing list discuss at mpich.org<mailto:discuss at mpich.org>
To manage subscription options or unsubscribe:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mpich.org%2Fmailman%2Flistinfo%2Fdiscuss&data=04%7C01%7Ckurt.e.mccall%40nasa.gov%7C132072f5f8994f8cb31308d9e2966ce7%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637789957980739463%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5q%2FzYyNnO9HMxQ%2Bq1xDDaCLC06vCuCDolIuS1Oe%2FLNo%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20220128/79cb1b1b/attachment-0001.html>
More information about the discuss
mailing list