Notes 2017 04 13

Participants

• Keeran Brabazon
• Jean-Baptiste Besnard
• Chris Chambreau
• Esthela Gallardo
• Marc-Andre Hermanns
• Kathryn Mohror
• Jeff Squyres
• Soren Rassmussen

Notes

MPI_T events

• Who owns the enum returned by MPI_T_event_get_info? Who frees the memory?
  • No explicit call exists to free enums currently returned by MPI_T calls
  • An enum is therefore valid between initialization and finalization of MPI_T
  • The implementation manages the memory, the user does not need to free anything here
• The list of datatypes in MPI_T_event_get_info is managed by the user?
  • Behavior similar to name and name_len: User can provide a zero for a length and gets the needed length returned
  • An initial call may be required anyway to query the length of name and descr
• Usage of verbosity parameter in MPI_T_event_enum_get_info is unclear
  • Its semantics is symmetric to the verbosity parameters in pvar and cvar calls
  • How would a tool only query the events (or pvars/cvars) of a certain verbosity?
• Dynamic sources
  • The existence of a (potential) new source for the registered events is indicated by a callback
  • The callback should be specified as a (the only) required callback (if an implementation chooses to provide events)
  • Callback functions should also be provided with an indicator whether memory allocations are allowed or not
    • Other system-level operations may be interesting here as well
    • Check the POSIX defintions of different levels (what about Windows?)
      • Search for async. signal safety and go from there
    • Maybe first version of the interface only defines the most-restrictive (inside an interrupt handler) for all callbacks
    • Tools that need to allocate memory would have to employ standard techniques to defer allocation to a safe moment (inside the next PMPI-wrapper call?)
    • Should the safety level be provided directly to the callback or "hidden" in the meta data and accessible via an extra call, e.g., MPI_T_event_get_sync_signal_safety?

Universial IDs

• Jeff updated the ticket text
• We should require unique IDs, and with it all implementors to obtain a CID in the first version
• As discussed the 700 USD should not be a show-stopper for any implementor, and unique IDs for all pvars/cvars/events would improve the situation a lot for tools

uint64_t MPI_T_pvar_get_uid(int pvar_index)

uint64_t MPI_T_cvar_get_uid(int cvar_index)

uint64_t MPI_T_event_get_uid(int event_index)

MPI Timer

• Timer should be as fast as possible, so data should be provided with a single call, not requiring any additional calls.
• Struct MPI_Time should therefore have accessible members for seconds and the rest
  • Should we use NANOSEC or PICOSEC for the rest?
    • Pico-seconds would be the next order of magnitude in resolution
    • No clock interface currently provides this, but it would make the interface a bit more future safe?
  • What about the call to MPI_T_time_get_resolution to return whether this is pico seconds or nano seconds?
  • Should the clock source also be encoded here (see clock_gettime)
  • Can we scale fast from pico to nanoseconds?