May 2009 - mpiwg-tools - mailman3.cels.anl.gov

Re: [Mpi3-tools] Meaning of meaning of unique_id in mqs_communicator?
by Geoffrey R. Paulsen 11 May '09

11 May '09

Ashley, In reading HP-MPI source code, which has implemented the MSQ interface quite a while back, I believe that we return a value which conforms to the definition (b) below. I'm not sure I understand the difference between (b) and (c). I hope this helps, Geoff Paulsen HP-MPI Regarding Ashley Pittman's message: > > All, > > I've raised this point before on the anl mpi-debugger mailing list > however I'd still like resolution to the issue so I hope it's not > in-appropriate to raise it again in this forum. > > The problem I have is that when inspecting a parallel job in a debugger > I find I'm unable to match communicators across MPI processes so it's > impossible to tell which communicators in process A match which > communicators in process B. > > Each MPI process reports the existence of a number of communicators to > the debugger and through the unique_id field of the mqs_communicator > type it reports a ID for this communicator. It's the meaning of this ID > which I'd like clarified. > > There are three possible interpretations for this field. > > (a) The ID could be unique to this process, typically a pointer to some > internal struct. > > (b) The ID could be unique to this process and also common to all > members of the communicator, regardless of the MPI process on which they > reside. > > (c) The ID could be both unique to this process, common to all members > of the communicator and also unique to this communicator. > > Current MPI implementation's seem to favour (a) however this doesn't > give the debugger enough information to match communicators in one > process with communicators in a different process. > > I believe the intention of the code when written was (b) and this does > allow the debugger to match communicators across processes. > > This issue presents me with real problems, I have a collective state > inspection tool which is capable of detecting deadlock and spotting > errant processes however without the ability to match communicators > across processes it's functionality is severely crippled. > > If possible could we discuss this on the call with a view to clarifying > the current meaning and if necessary devising other means of exporting > the required information. > > Ashley Pittman, > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

[Mpi3-tools] Meaning of meaning of unique_id in mqs_communicator?
by Ashley Pittman 11 May '09

11 May '09

All, I've raised this point before on the anl mpi-debugger mailing list however I'd still like resolution to the issue so I hope it's not in-appropriate to raise it again in this forum. The problem I have is that when inspecting a parallel job in a debugger I find I'm unable to match communicators across MPI processes so it's impossible to tell which communicators in process A match which communicators in process B. Each MPI process reports the existence of a number of communicators to the debugger and through the unique_id field of the mqs_communicator type it reports a ID for this communicator. It's the meaning of this ID which I'd like clarified. There are three possible interpretations for this field. (a) The ID could be unique to this process, typically a pointer to some internal struct. (b) The ID could be unique to this process and also common to all members of the communicator, regardless of the MPI process on which they reside. (c) The ID could be both unique to this process, common to all members of the communicator and also unique to this communicator. Current MPI implementation's seem to favour (a) however this doesn't give the debugger enough information to match communicators in one process with communicators in a different process. I believe the intention of the code when written was (b) and this does allow the debugger to match communicators across processes. This issue presents me with real problems, I have a collective state inspection tool which is capable of detecting deadlock and spotting errant processes however without the ability to match communicators across processes it's functionality is severely crippled. If possible could we discuss this on the call with a view to clarifying the current meaning and if necessary devising other means of exporting the required information. Ashley Pittman,

1 0

[Mpi3-tools] PMI initial description
by Pavan Balaji 10 May '09

10 May '09

Hi all, I have attached a brief description of PMI with this email so that folks have a better idea on what it is (these are basically Bill's notes slightly modified to not be MPICH2 specific). On the last call it wasn't clear whether the group should pursue this. If there is time, it will be preferable if we can make a decision on this on tomorrow's call. Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji Basic Concepts ============== The basic idea is that all interaction with external process and resource managers, as well as the exchange of any information required to contact other processes in the same parallel job, takes place through the process management interface or PMI. There are four separate sets of functionalities: 1. Creating, connecting with, and exiting parallel jobs 2. Accessing information about the parallel job or the node on which a process is running 3. Exchanging information used to connect processes together 4. Exchanging information related to the MPI Name publishing interface While these can be combined within a single, full-featured process manager, in many cases, each set of services may be provided by a different actor. For example, creating processes may be managed by a system such as PBS or LoadLeveler. The Name publishing service may be accomplished by reading and writing files in a shared directory. Information about the parallel job and the node may be provided by mpiexec, and the connection information may be handled with a scalable, distributed tuple-space system. There are three groupings of processes that are important in understanding the process manager interface. Process: An MPI process; this is usually an OS process (but need not be; an example would be threads in a language that keep named globals thread-private by default). Job: This is a collection of processes managed together by a process manager that understands parallel applications. A job contains all of the processes in a single MPI_COMM_WORLD and no more. That is, two processes are in the same job if and only if they are in the same MPI_COMM_WORLD Connected Jobs: This is a collection of jobs that have established a connection through the use of PMI_Job_Spawn or PMI_Job_Connect. If any process in a job establishes a connection with any process in another job, then all processes in both jobs are connected. That is, connections are established between jobs, not processes. This is necessary to implement the MPI notion of connected processes. In addition, it is desirable to allow the PMI client interface to be implemented with a dynamically loadable library. This allows an executable to load a version of PMI that is compatible with whatever process management system will be running the application, without requiring the process management systems to implement the same communication (or wire) protocol. The consequence of this is that the pmi.h header file is standardized across all PMI client implementations (in MPICH2's PMI v1, each PMI client implementation could, like MPI, define its own header file). Sample API ---------- int PMI_Init( int *spawned, int *size, int *rank, int *appnum ) int PMI_Finalize(void) int PMI_Abort(int flag, const char msg[] ) PMI_KVS_Put( const char key[], const char value[] ) PMI_KVS_Get( const char jobId[], const char key[], char value [], int maxValue, int *valLen ) PMI_KVS_Fence(void)

1 0

[Mpi3-tools] MPI3 Tools WG Telcon, Monday 5/11
by Martin Schulz 08 May '09

08 May '09

Hi all, As announced last week, we'll have our next MPI tools TelCon next Monday at 8am PDT, 11am EDT, 5pm MSZ. The plan is to talk about implementation issues and challenges for interfaces like Sun's proposed state profiling interface. One of Sun's developers, Terry Dontje, will join us for the call and we also hope to get some feedback from the development teams at Intel and IBM (as of last call's action items). If there any other topics that should be on the agenda, please let me know. The dial-in information is as usual: > Toll Free Dial In Number for Offsite Participants: 866-914-3976 > International Access/Caller Paid Dial In Number: 925-424-8105 > Dial In Number for LLNL Onsite Participants: 4-8105 > > Access Security Code: 860609 # Talk to you on Monday, Martin PS: All previous meeting minutes as well as meeting times and call-in information are on the MPI3 Wiki at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools _______________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulz6 CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0