Dave,
unless you are doing direct launch (for example, use 'srun' instead of
'mpirun' under SLURM),
this is the way Open MPI is working : mpirun will use whatever the
resource manager provides
in order to spawn the remote orted (tm with PBS, qrsh with SGE, srun
with SLURM, ...).
then mpirun/orted will fork&exec the MPI tasks.
direct launch provides tightest integration, but it requires some
capabilities (a PMI(x) server)
are provided by the resource manager.
hopefully the resource manager will report memory consumption and so on
of the spawned process
(e.g. orted) but also its children (e.g. the MPI tasks)
back to SGE, and if i understand correctly, memory is requested per task
on the qsub command line.
i am not sure what is done then ... this requirement is either ignored,
or the requirement is set per orted.
(and once again, i do not know if the limit is only for the orted
process, or its children too)
Bottom line, unless SGE natively provides PMI(x) capabilities, the
current "tight integration" is imho the best we can do
Cheers,
Gilles
On 7/28/2017 12:50 AM, Dave Love wrote:
"r...@open-mpi.org" <r...@open-mpi.org> writes:
Oh no, that's not right. Mpirun launches daemons using qrsh and those
daemons spawn the app's procs. SGE has no visibility of the app at all
Oh no, that's not right.
The whole point of tight integration with remote startup using qrsh is
to report resource usage and provide control over the job. I'm somewhat
familiar with this.
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
