[mpiwg-tools] Meeting March 21, 2019

Thu Mar 21 12:16:54 CDT 2019

Hi Ralph and all,

Definitely useful use case!

I have not been able to call into this concall series, but I have a general input as I’m pretty familiar with these debug interfaces (as well as resource manager mechanisms).

Generally speaking, I like any standard interface to be lean and mean with good separations of concerns so that many implementors can implement the interface. In that context,  it seems it would be good to discuss what functionalities should be implemented at the tool’s side and what should be provided by the new MPIR2 standard.

In this particular use case, a remote tool can easily ssh into the remote node and co-locate an agent to create a session like you are describing using whatever requisite security mechanism for the site. If the standard interface tries to solve this problem within itself, I fear it may lose good separation of concerns and the interface can quickly become unwieldy.

But I do agree it would be good to capture this use case somewhere and factor that into when MPIR2 interface starts to emerge.

Just my $0.02.

Dong

From: mpiwg-tools <mpiwg-tools-bounces at lists.mpi-forum.org> on behalf of Ralph H Castain via mpiwg-tools <mpiwg-tools at lists.mpi-forum.org>
Reply-To: "mpiwg-tools at lists.mpi-forum.org" <mpiwg-tools at lists.mpi-forum.org>
Date: Thursday, March 21, 2019 at 9:37 AM
To: "mpiwg-tools at lists.mpi-forum.org" <mpiwg-tools at lists.mpi-forum.org>
Cc: Ralph H Castain <rhc at open-mpi.org>
Subject: Re: [mpiwg-tools] Meeting March 21, 2019

Quick follow-up to today’s call. I’d like to suggest adding a bullet to the list of requirements for supporting remote tool connections - i.e., where the tool is executing on a node different from the process to which it is attached (RM or launcher). This is a really useful capability. For example, I am currently running a GUI-based tool on my desktop computer that is attached and controlling an application launcher on a cluster 200 miles away (I confess it is using PMIx). Yes, I could login to that machine, but then I either am limited to a text screen or must utilize secondary tools like VNC or X11. Much cleaner to just directly connect/control.

This is where I was going with the ability to detach and remain running - however, I think some explicit language about remote operations might be useful.

HTH
Ralph

On Mar 21, 2019, at 6:46 AM, Mohror, Kathryn via mpiwg-tools <mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>> wrote:

Hi all,

Thanks Dick and John for sending your use cases and straw men!

Here are a couple more docs I found from our discussions in the past:

  1.  Straw man from Anh Vo (mpi_debugging_requirements-AV-05-10-2016)
  2.  Needs from Allinea debugger as described by Chris January (mpi_debugging_requirements (002))
  3.  Notes from Forum meeting 2/27/2017: https://github.com/mpiwg-tools/tools-issues/wiki/Notes-2017-02-27

Talk to you all soon!
Kathryn

From: mpiwg-tools <mpiwg-tools-bounces at lists.mpi-forum.org<mailto:mpiwg-tools-bounces at lists.mpi-forum.org>> On Behalf Of Dirk Schubert via mpiwg-tools
Sent: Thursday, March 21, 2019 3:43 AM
To: mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>
Cc: Dirk Schubert <Dirk.Schubert at arm.com<mailto:Dirk.Schubert at arm.com>>
Subject: Re: [mpiwg-tools] Meeting March 21, 2019

Hi Kathryn,

The following use cases are important for Arm Forge (debugger DDT and profiler MAP).

Use case 1: Launch an MPI job under the control of a tool.

Input: The user's regular command line to start the MPI job, for example "mpirun -n 256 ./wave_c". Why? To make it as friction-less as possible to use a tool.

NB: The tool does not want to parse or interpret the MPI starter arguments, as the tool has no knowledge of all possible MPI starter arguments.

Requirements:

  *   Hold MPI processes for the tool to attach to them and to release them when attached.
Q: Where are processes held? In MPI_Init or _start?
  *   Spawn tool daemon on nodes where job is running.
Q: Co-spawn or separate?
Q: One per node or one per process?
Q: Environment? Same general environment as MPI processes instead of restricted environment (e.g. $HOME not set or chroot).
  *   Acquire the process table (rank, hostname, pid and executable path) of spawned MPI processes.
Q: Only global proctable or additionally local (per node) proctable?
  *   [Optional] Modify the environment of the MPI processes before launching, such as prepending to LD_PRELOAD or LD_LIBRARY_PATH to inject preloads into the MPI processes (but not other processes, such as MPI daemons or tool daemons).
Q: When? It would be great if modifying the environment could be done just before the MPI processes are forked/exec’ed. Why? For our profiler MAP we need to preload an MPI specific PMPI library, but for some “MPI” starter processes such as srun we don’t know the real MPI implementation that is used. Acquiring a partial process table (no PIDs) and inspecting the binaries pointed to by the executable paths, could allow us to detect the MPI implementation.
  *   [Optional] Raise queue allocation request and granted events to allow the tool to disable startup timeouts temporarily while a queue allocation is in progress, as this can take a long time (applicable to srun).
  *   [Optional] Scalable startup of tool daemons and shipping of preloads without touching the parallel file system on compute nodes. For example, pushing of daemon executable file (and dependencies plus preloads) to ram disk on compute nodes or Spindle?
Q: Where files are pushed? A job specific temporary directory such as /tmp/mpi.job.1234/... or configurable?
Q: How can the tool query the location of pushed files to reference them?
Q: Who cleans up the files afterwards? The MPI job/starter itself or the tool?
N: Files should be pushed with original file’s permissions.

NB: Optional requirement = A tool could ultimately work without it, but I very much would like to see it supported.

In PMIx this is the “indirect” use case and Ralph Castain and I have been working together since a while to make sure this use case will be supported by PMIx (excluding some optional requirements for now).

Additional questions/notes:

  *   How will the handshake work, such that the MPI starter knows it's running under a tool and when it's possible for a tool to interact with the MPI starter process?
  *   The handshake must support cases where the MPI starter filename that is provided by the user is a wrapper around the real MPI starter executable, for example XALT.
  *   In PMIx both problems are solved with PMIX_LAUNCHER_PAUSE_FOR_TOOL=1 and PMIX_LAUNCHER_RENDEZVOUS_FILE=<filename>.
  *   Will only the tool or also the tool daemons interact with the MPI job?
  *   Security, for example USER B shall not be able to attach to MPI job of USER A.
  *   Anything to consider for MPMD or heterogeneous systems?
  *   Must be scalable.
  *   Must not require a debugger.

Use case 2: Attach to a running MPI job with a tool.

This use case is a subset of use case 1 with the following requirements:

  *   Acquire the process table of spawned MPI processes of MPI job.
  *   Spawn tool daemon on nodes where MPI job is running.
  *   [Optional] Scalable startup of tool daemons without touching the file system.

Thanks,
Dirk

Dirk Schubert | Arm | Staff Software Engineer
dirk.schubert at arm.com<mailto:dirk.schubert at arm.com>
allinea is now part of Arm

________________________________
From: mpiwg-tools <mpiwg-tools-bounces at lists.mpi-forum.org<mailto:mpiwg-tools-bounces at lists.mpi-forum.org>> on behalf of Mohror, Kathryn via mpiwg-tools <mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>>
Sent: 17 March 2019 14:46
To: mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>
Cc: Mohror, Kathryn
Subject: [mpiwg-tools] Meeting March 21, 2019

Hey everybody,

For our call this Thursday (3/21) we’ll come back to debugger topics again. The call is at the usual time in the US (8 am Pacific/ 11 am Eastern / 4 pm CET) but note that the US has moved to DST but I don’t think the EU has done so yet.

Webex Info:
  https://apps.fz-juelich.de/scalasca/mpiwg-tools-webex/index.php

Agenda:

In the last debugger call, I said that the plan for this meeting would be to get an overview of OMPD and start talking about analogous interfaces for MPI (e.g. revamp MQD). However, in the meantime, I was convinced that we should focus on process acquisition first. So, the plan will be to talk about process acquisition in this meeting. I’ll go through our notes from 2017(ish) to hopefully find the straw men we drafted back then. Please bring your use cases and any ideas you have on this front.

_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>, https://people.llnl.gov/kathryn
Data Analysis Group<https://computation.llnl.gov/casc/data-analysis-group> @ Lawrence Livermore National Laboratory, Livermore, CA, USA

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
<mpi_debugging_requirements-AV-05-10-2016.pdf><mpi_debugging_requirements (002).pdf>_______________________________________________
mpiwg-tools mailing list
mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20190321/1bfbbf5f/attachment-0001.html>