[Spec] Publish DFLASH verify read-done event for fine-grained WAR barrier - #29541
Conversation
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
1dd9390 to
0ddcba7
Compare
0ddcba7 to
9df2fa9
Compare
788ee42 to
2307cb2
Compare
f6051be to
b0b8aab
Compare
7888a48 to
25f4857
Compare
b0b8aab to
0f9c94c
Compare
0f9c94c to
1d369b7
Compare
|
/rerun-test registered/spec/dflash/test_dflash.py registered/cuda_graph/piecewise/test_pcg_with_speculative_decoding_dflash.py registered/spec/test_gemma4_dflash_31b_extra.py (latest main) |
|
Results for 🚀 🚀 |
|
Results for 🚀 🚀 ⛔ ⛔ |
|
/tag-and-rerun-ci |
What
Publish the WAR
read_doneevent from the DFLASH target-verify forward so the scheduler's global_apply_war_barriertakes the fine-grainedwait_event(read_done)fast path instead of the coarsewait_stream(forward_stream)fallback.Why it is valid
The target-verify cuda graph builds its page table in
load_batch(pre-replay) and then replays reading only that static snapshot. So the forward finishes reading the sharedreq_to_token/ SWA buffers before replay —read_doneis recorded at exactly that point, so it is a sound WAR signal.WAR ordering
The over-alloc write to
req_to_token(plan stream) stays ordered after the previous forward's read through this chain:prepare_for_decodealready doesplan_stream.wait_stream(schedule_stream)(originally to see the scheduler's filter/merge writes), so the plan-stream over-alloc write inherits theread_donedependency transitively — no explicit plan-stream wait is added. The barrier now waits only untilreq_to_tokenhas been read (start of the verify forward) instead of the whole forward, recovering the overlap window the coarse fallback serialized.Dependencies
Builds on #29556 (merged) — removed
verify_doneand the dflash_war_barrier_enabledopt-out, routing dflash through_apply_war_barrier. Independent of #29343 (fa3).CI States
Latest PR Test (Base): 🚫 Run #28342455012
Latest PR Test (Extra): ❌ Run #28342454942