Skip to content

The admission governor reads the machine once and then lets a whole fan start against that one reading #878

Closed

Description

@santoshkumarradha

What happens

runFrontier (internal/session/task_run.go:~1411) takes busy := g.governor.holds() once, before the lock, behind a one-second cache, and then marks every ready node running against that one bool. With task.parallel = 0 (the default) and a fan of twenty (#874 raises taskFanLimit 5 → 20 and taskDepthLimit 2 → 3 on speed/task-start), twenty children start in one pass: twenty agents, twenty worktrees, later twenty builds, all admitted against a reading taken before any of them existed. Load average is a one-minute decayed figure and cannot see a burst. The shape was previously reachable only from uncapped conversation roots; on the integration branch it is the ordinary path at four times the width.

Replication

A scripted internal/session run: one parent node hands out twenty ready children with task.parallel unset; observe that governor.holds() is consulted once per frontier pass and every child is admitted in the same pass (assert on the admission order and the number of governor readings). No live model needed.

Acceptance (end to end first)

  1. internal/session: with a memory floor that would admit N children and a fan of 20, exactly N start in the first pass and the rest are held with waitingMachineBusy, the reading being taken again after each admission counts the admitted node's reservation, and the held ones start as the earlier ones settle. The design and the constant carry a measured per-node footprint, not a guess.
  2. internal/tui3: a held child's row says the machine word (task_run.go's waitingMachineBusy spelling), not slot.
  3. Manual: the section on why several things started at once says how many start at once and what holds the rest.

Where

internal/session/task_pressure.go, runFrontier in task_run.go. Design seam and the finding are written in docs/design/task-start/DESIGN.md (lane P of speed/task-start, PR #874). The wave speed/task-start should not promote to dev without this landing beside it.


Drafted with CodeAF · reviewed and owned by the author

Activity

  1. AbirAbbas commented on Sep 16, 2026

    @AbirAbbas
    Collaborator

    Fixed by #885, with #947 completing the accounting across every conversation in the process.

    Checked on dev at 77293538c: the frontier in internal/session/task_run.go asks the hold for each ready node and reserves the admitted lane before it considers the next, and internal/session/task_pressure.go defines the per-admission footprint the governor is asked with. TestOneReadingIsJudgedOncePerAdmissionWithTheStartedNodesCounted and TestEveryStartIsJudgedByTheGovernor pin the count (acceptance item 1), TestAHeldChildSaysTheMachineHeldItAndNotTheCap pins the machine busy row wording (item 2), and the tasks manual's "why several things started at once" section says how many start and what holds the rest (item 3).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething the code does that it should not

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions