prov/shm: Revert to a lock-unlock inject pool#12109
Open
zachdworkin wants to merge 3 commits intoofiwg:mainfrom
Open
prov/shm: Revert to a lock-unlock inject pool#12109zachdworkin wants to merge 3 commits intoofiwg:mainfrom
zachdworkin wants to merge 3 commits intoofiwg:mainfrom
Conversation
Contributor
Author
|
bot:aws:retest |
1 similar comment
Contributor
|
bot:aws:retest |
j-xiong
previously approved these changes
Apr 5, 2026
Remove the parallel command-inject resources and revert to using a lock-unlock inject buffer pool. Update the inject protocol to use the old method. There is a performance regression when using the "new shm" command-inject parallel data structure. This is due to the sender not being able to complete its transmission until the receiver returns the sender's command to the sender's return queue. In the old lock-unlock method the sender would allocate receiver side resources, copy its data into the receiver inject buffer and then complete. The old method allows MPIs and applications to assume that their inject message transmissions will complete quickly and since the new method does not complete `as` quickly it is likely the reason for this regression. Signed-off-by: Zach Dworkin <zachary.dworkin@intel.com>
Command stack is less likely to be used in the inject protocol when resources are on the receiver side. If the inject pool is above it then we have to jump less, and do not have to jump over the command stack, when accessing it. Signed-off-by: Zach Dworkin <zachary.dworkin@intel.com>
Use the ofi freestack instead of the smr freestack for the cmd stack. This is because we only need to push and pop on the sender side so we do not need the added functionality of the smr freestack. Both freestacks will use the same number of page grabs but the ofi freestack has a much smaller header so we prefer using it over the smr freestack. Signed-off-by: Zach Dworkin <zachary.dworkin@intel.com>
Contributor
Author
|
bot:aws:retest |
Contributor
Author
|
@sunkuamzn what is the AWS failure with this PR? |
Contributor
|
@zachdworkin There is single node unexpected message test timeout |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Remove the parallel command-inject resources and revert to using a lock-unlock inject buffer pool.
Update the inject protocol to use the old method.
There is a performance regression when using the "new shm" command-inject parallel data structure. This is due to the sender not being able to complete its transmission until the receiver returns the sender's command to the sender's return queue. In the old lock-unlock method the sender would allocate receiver side resources, copy its data into the receiver inject buffer and then complete. The old method allows MPIs and applications to assume that their inject message transmissions will complete quickly and since the new method does not complete
asquickly it is likely the reason for this regression.In addition we need to move the inject stack above the cmd stack in the shm region. This is because most of the time the new inject protocol will not need to use the cmd stack. If we swap the ordering in the region then we have to do less jumps through memory to get the resources we need.
We can also use the ofi freestack for the cmd stack because we only need to pop and push on the sender side so we don't need the extra functionality of the smr_freestack.