mirror of
https://github.com/deepseek-ai/DeepEP.git
synced 2026-11-05 00:47:32 +00:00
[PR #715] [MERGED] fix: add system-scope release before the GIN barrier when scaleup spans NVLink and RDMA #728
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepEP#728
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/deepseek-ai/DeepEP/pull/715
Author: @EvadLee
Created: 8/3/2026
Status: ✅ Merged
Merged: 8/4/2026
Merged by: @sphish
Base:
main← Head:pr/gin-barrier-fence📝 Commits (2)
7dcf493fix: Add fence.acq_rel.sys before the GIN barrier for mixed-fabric scaleup9d170b2fix: fence mixed-fabric writes in GIN barrier📊 Changes
1 file changed (+2 additions, -0 deletions)
View changed files
📝
deep_ep/include/deep_ep/common/comm.cuh(+2 -0)📄 Description
Problem
While integrating ElasticBuffer into SGLang, multi-node direct mode hangs non-deterministically at the GIN barrier:
Envrioment: 2 nodes x 8 H200, EP16
Root cause
When the scaleup team spans nodes,
kIsScaleupNVLink == falseand the data plane is mixed: same-node peers are written by rawptx::tma_store_1d, cross-node peers bygin.put. The GIN barrier never releases the NVLink-written half to system scope —flush()does not publish (gin.h:310-311) andsignal()defaults tocuda::thread_scope_device(gin.h:304-308). Device scope covers RDMA, since the NIC reads local memory, but not stores landing in another GPU.Fix
comm::gpu_barrieralready drains TMA stores before the barrier. Add a system-scope release there, on the path that publishes the raw NVLink writes:Validation
We could not reproduce this in a standalone unit test — it only shows up under a real multi-node workload, where the timing window is wide enough. Under SGLang on 2 nodes x 8 H200 (EP16, direct), the barrier timeout happens every time without these two lines, and never happens with them.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.