Fix: size HBG ready queues from reachable tasks - #1982
Conversation
- Count host tasks and Graph Definition node histograms at bind time - Size each queue to a bounded power of two and reject oversized graphs - Cover Qwen-scale populations and the reservation limit in shared tests
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe host build graph now computes ready-queue populations from submitted tasks and graph definitions. It derives per-queue capacities, rejects populations above the configured limit, and uses the capacities when reserving and initializing scheduler queues. ChangesReady-queue capacity derivation
Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk: ⚪ Minimal · up to The change sizes HBG ready queues from reachable tasks and rejects graphs above the supported bound; reported tests and performance checks pass, so no actionable merge-blocking risk remains. Sequence Diagram(s)sequenceDiagram
participant HostOrchestration
participant GraphDefinitions
participant ReadyQueuePopulations
participant SchedulerLayout
participant Scheduler
HostOrchestration->>ReadyQueuePopulations: Count submitted task-slot populations
HostOrchestration->>GraphDefinitions: Bind uploaded definitions
GraphDefinitions->>ReadyQueuePopulations: Add definition node populations
ReadyQueuePopulations->>SchedulerLayout: Derive per-queue capacities
SchedulerLayout->>Scheduler: Reserve and initialize queue storage
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
READY_QUEUE_OVERFLOWDesign
The ready queue has no recoverable full path, so its capacity is a correctness bound rather than a tuning hint. The host task window is scanned once after orchestration. Graph nodes are not materialized in that window, so each distinct Graph Definition is walked once to build a routing histogram, then that histogram is added once per Graph submission/replay.
Each queue receives the smallest power-of-two capacity that can hold its reachable population (minimum 2). The shared-memory arena remains fixed and reusable, with a bounded capacity of 32768 entries per queue. Inputs above that supported bound fail during bind instead of reaching a fatal queue-full condition on device.
This is intentionally scoped to HBG queue sizing: no retry/backpressure protocol or scheduler redesign is introduced.
Testing
mainGraphExecutionBatch16Seq3500, 3/3 rounds with golden validation passed (task_20260824_003633_278330810026); device time was 37.77-38.36 msPerformance check
A 100-round baseline/current comparison on the issue branch showed typical device latency unchanged within noise:
Fixes #1920