[mpiwg-tools] Meeting March 21, 2019

Thu Mar 21 11:36:44 CDT 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> 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:
> Straw man from Anh Vo (mpi_debugging_requirements-AV-05-10-2016)
> Needs from Allinea debugger as described by Chris January (mpi_debugging_requirements (002))
> Notes from Forum meeting 2/27/2017: https://github.com/mpiwg-tools/tools-issues/wiki/Notes-2017-02-27 <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 <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 <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 <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/a1e90ac8/attachment-0001.html>