fix(ci): synchronous data loading for hanging t5 functional tests - #5241
Closed
Connor-XY wants to merge 1 commit into
Closed
fix(ci): synchronous data loading for hanging t5 functional tests#5241Connor-XY wants to merge 1 commit into
Connor-XY wants to merge 1 commit into
Conversation
…5 functional tests t5_mcore_tp1_pp1_vp1 (+ the two *_resume_torch variants) intermittently hang in CI. The fault-handler dump shows the stuck rank's main thread parked in the input pipeline, not a collective: pretrain_t5.py:148 get_batch -> rerun_state_machine.py __next__ -> torch/utils/data/dataloader.py _try_get_data -> multiprocessing/queues.py:113 get (blocked) A dataloader worker fails to deliver the next batch, so that rank never enters the step's gradient all-reduce; the ranks that did get their data then time out in finalize_model_grads (600s NCCL watchdog) and the run aborts -- surfacing as a misleading "collective timeout". Training is numerically healthy up to the hang (no NaN). build_pretraining_data_loader uses num_workers=2 + pin_memory + persistent_workers and sets no DataLoader timeout, so a stalled worker blocks forever. The same recipe runs clean on fast local storage, so the trigger is the CI data mount / worker pipeline, not the model. --num-workers 0 loads batches in-process (no worker subprocesses, no pin-memory queue, worker_init_fn skipped), removing the queue.get hang surface. Test data is tiny so the perf impact is negligible. Note: candidate fix to validate in CI (the stall does not reproduce on fast local storage). If it still hangs with num_workers=0, the trigger is raw I/O on the data mount and the follow-up is a DataLoader timeout + local data staging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Connor-XY
marked this pull request as ready for review
June 9, 2026 22:30
Contributor
Author
|
/ok to test 4d26abc |
Contributor
Author
|
Superseded by #5253. |
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.
What
Set
--num-workers: 0(synchronous, in-process data loading) for the t5 functional tests that intermittently hang in CI:t5_mcore_tp1_pp1_vp1t5_mcore_tp1_pp1_vp1_resume_torcht5_mcore_te_tp1_pp1_vp1_resume_torchWhy
These hang in CI with a
finalize_model_gradsall-reduce timeout — but the fault-handler dump shows the stuck rank's main thread parked in the input pipeline, not a collective:A dataloader worker stops delivering batches → that rank never enters the step's grad all-reduce → the ranks that did get data time out (600 s NCCL watchdog). Loss is healthy up to the hang (no NaN), so it's the data pipeline, not the model/comms.
build_pretraining_data_loaderusesnum_workers=2+pin_memory=True+persistent_workers=Trueand sets noDataLoader(timeout=), so a stalled worker blocks forever. The same recipe runs clean on fast local storage → the trigger is the CI data mount / worker subprocess pipeline.--num-workers 0removes that surface (no worker subprocesses, no pin-memory queue); test data is tiny so perf impact is nil.Validation
Candidate fix — needs a CI run (
Run functional tests); the stall doesn't reproduce on fast local storage. If it still hangs withnum_workers=0(now in the inline read), the trigger is raw mount I/O and the follow-up is aDataLoader(timeout=)inbuild_pretraining_data_loader+ local data staging.🤖 Generated with Claude Code