On Tue, 2 Aug 2011 11:54:37 -0700, Michel Bourget <[email protected]> wrote: > > > > It isn't exactly clear what the strack() interface you are proposing > > would do. Is this a replacement for srun? > > > Hello Mark, > > No. Just like sattach() isn't a replacement to srun().
Ok, sorry I probably just didn't read the description correctly. > > Why not just have SGI MPI > > users use your mpirun under a SLURM allocation? > > The contractual requirement we have is 'srun a.out', ie NO mpirun. > Heh, ok fair enough. > > If srun isn't really > > launching all tasks, then there really isn't that much benefit to > > using srun that I can see. > > > > The SGI MPI plugin takes care of that by translating SLURM_STEP_NODELIST > and SLURM_STEP_TASKS_PER_NODE into appropriate sgimpi specifications. > Then , it is launched only when SLURM_PROCID=0. I can see similarities with > the "HAVE_FRONT_END" concept. > > > If you want the MPI launcher to be launched with srun, your mpirun > > could run something like "srun -N1 -n1 mpi_launcher..." > > > > Or maybe that is what you are already proposing? > > I am proposing something like sattach(). strack( job_it, step_id , ... ) > > Given valid job_id.step_id pair, it would teach slurmd-or-slurmstepd > currently loaded > plugins to track( add, replace ? ) the current pid/pgid/whatnot ( or > supplied values ). > > I mention "replace" because we could think the initial slurmstepd > could go away while another instance of slurmstepd ( triggered by an > strack ) kicks in. > > I mention "add" because we could think the initial slurmstepd stays > there while another parallel slurmstepd is kicked in to monitor another > pid/pgid pairs. Issue with that is linuxproc/job_acct_gather are single > container_id oriented. Or am I wrong completely ? Ok, I think I understand what you are proposing with strack(), but it might help if you walk through an MPI launch using your proposed strack() interface. I am still not 100% sure why the SGI mpi launcher would need something like strack, but that probably isn't your fault. I'm sorry if I'm being unnecessarily dense. mark
