[mpiwg-tools] MPI_T usage question: other sensors

[Schulz, Martin]

Hi Jeff, 

On Dec 19, 2013, at 3:29 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
 wrote:

> 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.

I would say not only for tools - if you wanted to get access to this information within MPI, you should probably consider PAPI as well, since it is (to my knowledge) the only reasonably portable way to get to this kind of information.

> 
> 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.

Hiding the symbols should work, but I am also worried about the underlying mechanisms to query data aren't mutually exclusive, i.e., I am not sure if two independent copies of PAPI can run concurrently (for any type of data that is being accessed).

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

Not lately - I am sure they are interested in it, but I doubt they will do it themselves. If someone else does it, they will most likely host the plugin and offer it as part of their distribution.

Martin


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

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA