[antiguru]

Every frontier advance appends an empty batch to each arrangement at spine layer 0. When a worker's smallest batch holds a single update, it sits at layer 0 too, so every tick starts a merge there. The exertion policy grants effort for any layer with two batches, which re-activates the arrange operator, and the merged batch moves back to layer 0, so the cycle repeats for as long as the arrangement is idle.

Measured on a 2-worker replica with a small join and reduce, the affected ArrangeAccumulable and ReduceAccumulable operators drop from 2.07 to 1.02 schedules per tick, their enclosing BuildRegion from 4.10 to 1.52, and merge grants from 54 to 15 per second. A plain differential reproduction shows the same pattern, and TimelyDataflow/differential-dataflow#1063 fixes the spine side. Turning exertion off entirely did not change replica CPU measurably on a 426-dataflow workload, so this removes wasted wakeups rather than a large CPU cost.

Layer 0 merges hold at most two updates and complete with the next insertion's fuel, so the policy now stops before layer 0. The new dyncfg compute_arrangement_exert_skip_layer0 (on by default) controls this. The policy is installed into each timely runtime before configuration arrives, so compute stores the flag in a process-wide atomic on each configuration update and the policy reads it per evaluation, which lets the flag be turned off without a replica restart. The policy moves into exert_effort with unit tests for both flag settings.

🤖 Generated with Claude Code