RMA WG 11 02 2020

Agenda

• Go over all active topics listed on the RMA WG wiki page.
• Add the link to the corresponding ticket for each topic.

Attendees

Did not record.

Notes

• New proposal shmem_quiet_all (Naveen): may be added to RMA WG or Threads WG. #453
• SHMEM_TEAM_PTR (Jim): Prefer to hand over to someone. Please contact Jim or follow up on the ticket if you are interested. #319
• Noncontiguous communication (Jim):
  • Have several proposals listed at #365
  • Have read the Block Interleaved API, need more time to study other options.
  • One concern is no strong application support. Might find examples from NVSHMEM customers.
• Signal API (Jim):
  • Functionally identical to shmem_put_signal with 0 byte transfer, but the new API is more straightforward
  • Naveen: has concern related to multi-rail network. E.g., shmem_put_signal will use a single NIC, how to deal with separate put + signal?
  • Jim: has to require the user to call fence (or quiet) explicitly to ensure ordered put + signal
  • Manju: need stronger motivation for the proposal. E.g., the user has to call extra fence before signal.
  • Jim: also benefits performance as it saves a conditional check; inlining might get rid of the check but it may also cause some overhead
  • Min: we have observed significant instruction cache misses when do full-inlining with MPICH.
• GPU (Jim):
  • Memory space is a prerequisite
  • Need coordinate with Khaled to get generic API proposal that covers both NVSHMEM and ROC_SHMEM
  • Potential proposal would be to add multithreading resource input in existing RMA API. This will allow the runtime to parallelize large PUT/GET by using available threads
  • Need more understanding on utilization of context
  • Min: might need a separate GPU chapter since the new API might not benefit CPU-oriented programs.

Agenda for the next meeting

• Wasi will present performance study regarding user-level threads