[mpiwg-tools] MPI_T usage question: other sensors

[Jeff Squyres (jsquyres)]

In Dec 18, 2013, at 8:19 PM, Schulz, Martin <schulzm at llnl.gov> wrote:

> I agree that a single interface to extract any kind of information from a system (MPI and beyond) would be very helpful and make our tools simpler. As Michael, though, I always thought of PAPI being that unifying interface - it should be very easy to write an MPI_T component to PAPI (in fact, I talked with Dan Terpstra from the PAPI team a few years ago when MPI_T was still under design and he thought that should work) and with that offer all MPI_T counters through PAPI (probably not the control variables, though). This should also allow us to provide "standardized" names for common performance variables (similar to what PAPI does for HW counters).
> 
> The situation changes a bit, though, if MPI implementations query other information, like temperature or power, for themselves (Jeff, was this why you were asking?). In this case, the MPI implementation should use a standardized interface like PAPI itself (to avoid conflicts with tools), which could lead us to some strange circular SW dependencies.

Yes, this is what I was asking.

If PAPI is going to be the standardized interface for tools to use, that's fine.

MPI's could certainly hide a private copy of PAPI in their internals (done correctly, it would avoid any symbol conflicts with application-linked in PAPI instances), but it sounds like it would be kinda wasteful.

Has anyone talked to the PAPI people recently to see if they're still interested in hooking up to MPI_T?

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/