-
Notifications
You must be signed in to change notification settings - Fork 447
PLUGINS/UCX: wait for in-flight transfers before release() returns #2044
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
vedularaghu
wants to merge
2
commits into
ai-dynamo:main
Choose a base branch
from
vedularaghu:vedularaghu/ucx-drain-inflight-on-release
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently there is no proper "abort" functionality in NIXL, we are discussing it.
@mkhazraee
But I'm afraid that this approach does not really solve the problem, just hides it a bit by doing 10s extra polling, but then it still fails the same way..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed - this isn't an abort, and I don't want to claim it is.
To split the two cases apart:
Transfer can still make progress. This is the ordinary
releaseXferReq()-mid-transfer path, and todayrelease()returns with the RMA still outstanding. The new gtest measures it: with the drain removed, only 8 128 of 67 108 864 bytes of a READ had landed whenreleaseXferReq()returned (0 bytes with no progress thread). The caller is free toderegisterMem()at that point, anducp_mem_unmap()frees a memh the request still holds a raw pointer to. The drain does close that window, and it costs ~300 ms for a 64 MiB transfer.Transfer can never make progress. You're right that the timeout doesn't fix anything here. After 10 s
release()returns anyway, the operation is still outstanding, and the caller's memory still isn't safe to deregister - all the deadline buys is an error line instead of silence. Only a real abort helps, and that's yours to design.So I'd frame this as: it fixes the case where waiting is sufficient, and it makes the case where it isn't sufficient visible instead of silent. If you'd rather not carry the 10 s knob at all and wait for proper abort support, we're happy to hold or close it - the part we'd like to avoid keeping is
release()returning, in the normal case, while UCX still holds a pointer to a memh the caller is about to unmap.Separately: the production evidence we gathered for #2047 supports your diagnosis on the other thread. On a wedged pod (NIXL 1.3.2, UCX debug logging) there were 156
set_ep_failed status Endpoint timeout on lane[N]events over the wedge, 27 of them on the exact rank whose handle stalled, while NIXL reportedNIXL_IN_PROGthroughout. AFAILEDendpoint with a permanently outstanding request is exactly what you described, and it points at yourcheckConnection()-on-NIXL_IN_PROGPOC as the primary fix rather than anything in these two PRs. Details in #2047.