-
Notifications
You must be signed in to change notification settings - Fork 41
RMA WG 11 29 2018
Md edited this page Nov 29, 2018
·
1 revision
- Discussion of interaction between put-with-signal and wait operations
- David Ozog, Wasi Rahman, Jim Dinan (Intel)
- Anshuman Goswami, Akhil Langer (Nvidia)
- Min Si (ANL)
- Naveen Ravichandrasekaran (Cray)
- Manjunath Gorentla (Mellanox)
- None
- (Naveen) Non-blocking AMO will be queued for reading.
- (Jim) SOS implementation for non-blocking AMO. Unit tests added.
- (Naveen) User option for Shmem_wait with put_signal added
- (Anshuman) 3 options: shmem_p and wait_until should work. Shmem_p can be used for sync. Shmem_p cannot be used for sync.
- (Anshuman) Shmem_wait cannot react to partial updates.
- (Naveen) The current implementation is limited to 2 PEs
- (Jim) For symmetric data segment, it should not be limited to 2 PEs. If atomic for signal is used, there should be correct well-defined behavior.
- (Naveen) Depending on the hardware, signal update can be anything. We should not explicitly say the operation type for signal update.
- (Jim) In such case, quiet or fence should guarantee completion of the signal operation. If shmem_p is not made compatible with wait, then the semantics are well defined. Keeping put_signal operation as point-to-point sync is the better choice. Texts need to be added to make sure users do not use this in producer-consumer scenario.
- (Naveen) The signal update should be atomic. Implementation-wise, it can be globally visible or only to the target.
- (Jim) It should be similar to scalar put semantics
- (Manju) From x86 perspective, can there be a single copy atomicity guarantee?
- (Jim) A pseudocode example to present the case where single-copy atomicity fails on x86?
- (Naveen) Would wait to hear input from Pasha
- (Jim) One way is to look at the memory after a NIC event. Reference to a PCIe Spec would be helpful
-
Working Groups
-
Errata