Open Interface Enables Parallel Applications Debugging
Like many companies who initially developed their offerings for the high performance computing market, Etnus LLC is finding that their TotalView debugger product has the potential for a much larger audience. Following the HPC trend in multi-core processors, multi-processor servers and cluster architectures into the commercial space, Etnus is demonstrating the competency of its debugger for a wide variety of multi-threaded software.
“HPC is our home base and core demographic,” says Chris Gottbrath, Product Manager for the TotalView debugger at Etnus LLC. But he notes that increasingly their customers come from the entertainment, financial, oil & gas and e-commerce industries. Companies in these industries are combining Linux and other open source software with the HPC competency of vendors like Etnus to build their solutions.
Gottbrath reports that Etnus has been helping to develop open interfaces for MPI (Message Passing Interface) to enable parallel application debugging. Today most supercomputers use MPI to support parallelization on distributed computing architectures, such as clusters. As clusters become widespread in enterprise deployments, more users will be relying on MPI to run their commercial applications. Gottbrath's highlights Etnus' collaboration with some of the MPICH and Open MPI developers to extend these interfaces for the next generation of the Message Passing Interface — MPI 2. HPCwire caught up with Gottbrath recently to discuss these latest developments.
HPCwire: Can you briefly describe how Etnus' TotalView debugger performs parallel debugging and talk about the importance of the MPI interface?
Gottbrath: TotalView performs parallel debugging by itself becoming a parallel application running alongside the user's application. TotalView begins by starting a lightweight (low resource usage) debugging agent on each node that is running part of the user's MPI program. These debugging agents — called tvdsvrs — can each use operating system level interfaces to interact with the users MPI tasks that are running alongside them on the same nodes. TotalView then controls the activity of all these lightweight debugging agents to provide the user with a comprehensive view into and fine level of control over the behavior of their MPI application that they are trying to debug.
In order to do this, one of the things that TotalView needs is a way to discover the identity and location of the potentially thousands of processes that make up an MPI job. The MPI process acquisition interface provides a way for the MPI itself to provide that information to the debugger.
Another interface that I will talk about is one that we use to obtain information about the state of the MPI message queues. Typically these queues are just used in a very transient way by the MPI implementations as they are processing messages. However when a message passing program fails to communicate correctly it often ends up leaving messages 'stuck' in the MPI message queues. This interface enables the debugger to give the user various high level and detailed views of these messages — and a quick way to diagnose an otherwise challenging set of problems.
Both of these interfaces were designed in collaboration with the MPI library development community and have been treated as open interfaces. Each interface has a reference implementation in the MPICH code base — so not only is the interface open but we can point MPI developers thinking about implementing the interfaces in their own code base to a full implementation that they can study. I think this has really fostered adoption of these interfaces both within the MPI library development community but also with a couple of other projects that have similar needs.
While I am talking about the existing interfaces I do want to place credit where credit is due. These interfaces are largely the work of Jim Cownie — who was at Etnus at the time, though is now at Intel. Jim worked closely with Rusty Lusk, one of the principle MPICH developers at Argonne on the original implementation. I've had the good fortune to be able to work with a wide range of other MPI developers as they work to incorporate these interfaces into their own implementations.
I am now leading a collaboration with the folks at MPICH and Open MPI to develop a new process acquisition interface that is capable of handling MPI 2 dynamic processes. We are quite consciously following the strategy of collaborative development, open interfaces, and open-source reference implementations that were so successful with these other two interfaces.
HPCwire: What specific kinds of information are available from the current MPICH and Open MPI interface that are being used by the TotalView debugger?
Gottbrath: The current MPI process acquisition interface tells TotalView the identity and location of the processes that make up an MPI job. One of the clever things about the interface is that it uses the fact that the debugger can read and write data from processes being debugged as the transport. What the MPI (or MPI runtime starter program) does is build up a table in memory that TotalView is able to look up like any other variable and read. Because MPI 1 has a very simple process lifetime — all MPI processes are created as a group and all of them are assumed to stay around till the whole program finishes — we only need a fairly light set of synchronization mechanisms. The debugger notifies the process that it is being debugged by setting a variable, the program starts the various MPI tasks in such a way that they won't run away, builds the table in memory and then notifies TotalView that the table is ready to be read, finally TotalView notifies the process that it is done reading the table and any remaining held tasks can be allowed to continue.
This is all done quite neatly with specially named functions and variables on the part of the MPI and the fundamental debugger operations on the part of TotalView.
The MPI message queue display interface provides the debugger with the envelope and contents of each message in the MPI send, receive or unexpected queues for each MPI process. Its implementation is a bit more sophisticated but operates on similar principles. Implementations take the form of helper libraries built by the MPI implementor to meet an API specified by Etnus. Each library encapsulates any implementation specific knowledge or techniques required to recover the message queue information out of a process. The helper library is loaded into the debugger which then provides low level memory read and write access to the MPI processes being debugged and makes API calls into the library as the user asks to look at the MPI message queues.
HPCwire: In your collaboration with the MPICH and Open MPI developers, what types of MPI interface enhancements are you most concerned about?
Gottbrath: My current work with the great folks in the Open MPI and MPICH teams focuses on capturing the good parts of the MPI process acquisition interface but extending the interface to allow the interface to be used in conjunction with MPI 2 dynamic processes. MPI 2 dynamic processes allow MPI programs to spawn new processes, join together previously separate MPI programs, and in certain circumstances split them back apart again. This makes for a much more complex world of MPI processes that the debugger needs to be made aware of. Synchronization is more complex and the performance-oriented nature of MPI means that we need to think very carefully about the costs of things like gathering together all the information about MPI processes in centralized locations.
My major concern as we design the interface is that like a good theory of the universe it be kept as simple as it can be, but no simpler. It needs to describe a complex situation, with MPI processes coming and going. It also needs to do this in a way that sacrifices little or no runtime performance. One of the major factors is that we want the MPI implementors to be comfortable shipping their libraries configured so that this information is gathered and made available to the user by default. Users will want to attach TotalView to their MPI jobs when they hang or crash and a nifty interface doesn't do anyone any good if it isn't turned on when the user sits down to troubleshoot their application.
HPCwire: What kinds of additional functionality would be available for TotalView users if you incorporated the MPI 2 interfaces that you are seeking?
Gottbrath: The principle advantage for users will be the ability to seamlessly debug MPI applications that take advantage of the new dynamic process features of MPI 2. MPI 2 was defined quite a while ago but only now are a number of different MPI libraries starting to support MPI 2 dynamic process operations. These are not something that every program is going to be immediately rewritten to start using, but they do open up significant new possibilities in the way that scientists and engineers can think about their MPI applications. Previously in order to use MPI the developer had to base their application on a fixed set of processes decided at launch time. With MPI 2 the set of processes that make up the MPI job can change in real time to respond to the demands of the task at hand.
Chris Gottbrath is Product Manager for the TotalView Debugger at Etnus LLC. He is focused on making it easier for programmers, scientists and engineers to solve even the most complex bugs and get “back to work.” He has pursued this goal in a variety of customer-focused technical roles at Etnus over the last 6 years. Prior to that, as a graduate student of astrophysics at the University of Arizona in Tucson, he wrote cosmological simulations (with the occasional bug) using C and MPI on a small-scale Beowulf cluster.