Notes 2016 05 19

Participants

• Jean-Baptiste Besnard
• Ralph Castain
• John DelSignore
• Dmitry Durnov
• Daniel Everett
• Marc-Andre Hermanns
• Kathryn Mohror
• Bob Moench
• Soren Rasmussen
• Martin Schulz
• Anh Vo

Notes

PMIX Debugger Launch

• Allinea sent their debugger requirements in a document to the mailing list
  • Kathryn will post this to the MPIR replacement page
  • Page 6, job starter arguments
    • There are some additions for IBM BG
    • Debugger executable on command line to co-spawn debugger with application
      • Why 1024? let's do it right argv style
    • Not defined how many characters, so could vary. They encountered 256 chars once
      • Implementation dependent
    • Are the tools and tools-arguments portable? Do they exist everywhere? Is it documented anywhere? - Yes it's in MPIR 1 section 9.16 as 1024 chars
      • We could fix it so it's not hardcoded at least
    • Starter process needs to store this information in its address space, store a pointer? And the debugger allocates something? Pass the beginning of the argv to the process?
      • No, needs to be readable within the process space
    • Continue asking for argv style array, no hardcoded requirements, something sufficiently large from POSIX requirements for argv. What is sufficiently large? - We don't know. On windows it's 32k for unicode
      • A configurable parameter when you build linux, a call to sysconf
      • Where does that leave us? 1024 might be big enough, but other implementations don't always support that much - RC says: Quick scan indicates that max arg size is all over the map, ranging from 512 to 2 MB. it can be defined by ARG_MAX or NCARGS, depending on the flavor of unix, but it looks like ARG_MAX is winning the battle

MPIR Replacement

• Backwards compatibility in MPIR-2
  • Is it up to the tool to be compatible with two interafaces?
    • As opposed to the new interface to be compatible with MPIR-1?
  • Tools at least want a way to query which interface is supported
  • Perhaps its enough that the symbols don't conflict with each other
    • So the two specifications are completely separate. Then it is possible for tools and implementations to support both
  • Dll locations
  • Different names? If there's no dll to load, then fall back to MPIR-1?
  • A different prefix for MPIR-2? MPIQ? :)
  • Variable set somewhere, so mpirun writer can see which one is used? So you set up the right proc table? - No, the implementation decides and then it's the tool's job to see what is supported. - No, how does mpirun know which interface to support? - So it's not doing both and using 2x resources? - Need to keep this in mind, a mechanism such that tool can assert. Messy
    • Initialize function should make it clear .. But how does mpirun know?
      • Need to know before proctable is created - a memory hog
      • Needs to know before the first event is raised, won't know if tool has just not called initialize yet?
    • How do you deal with attach?
      • Not going to know anything until attach. Lazily filling in proctable? Lazily detect if 1 or 2
      • Lazy fill is kind of normal, only fill if being debugged.
      • On attach, mechanism for telling implementation they are being debugged and then they fill the proctable.
        • The being_debugged flag, yes.
        • Allinea writes into a pipe.
        • For TV, a thread periodically polls to see if a debugger is attached. If TV sees proc table is not filled it, it says oh well and waits until next event and checks again
  • We all need to look at this and decide how to support legacy tools
  • Old vs new tool attach.. What about old tool attach, detach, new tool attach? What happens then?
    • On tool attach, state is supposed to be reset. How committed is the MPI implementation to whether using 1 or 2 in the first place?