From Observability
to Optimization

What Part 1
Established

Part 1 introduced the agentic slowpath and showed that latency amplification isn't a single-subsystem problem. The complete kernel control path a wakeup traverses is:

IRQ / timer / workqueue / I/O / MM / VFS
        ↓
completion / wakeup
        ↓
scheduler placement
        ↓
DVFS / CPUFreq
        ↓
cpuidle
        ↓
userspace resumes

The key observation: no single hop is catastrophic. The problem is multiplication across steps. An agent repeating this path thousands of times turns sub-millisecond overhead into user-visible latency:

Reactive is Wrong
for Control Loops

All current Linux power management is built on a reactive model: observe utilization, idle time, runnable state, queue pressure, cache state — then respond. That is correct for batch jobs and stable-load services. For agentic control loops it is systematically wrong.

Agentic workloads have a property no reactive heuristic can infer: short-term recurrence. If the kernel just woke a control-loop agent, the probability of another wait/wake/compute cycle within the next few milliseconds is near-certain. That predictability is the lever the patch series exploits.

The Same Loop,
Two Kernels

The optimization target is not a single wakeup. It is the repeated gap between wakeups — the window where the reactive kernel tears down warmth that the next step will immediately need.

Seven Subsystems,
One Control Signal

The design principle is consistent across all seven targets: inject the agent window into the existing decision point, rather than bypassing it. Each subsystem already has the right hook — the patch merely adds a time-bounded condition check at that hook.

if (task_agent_latency(p) && rq_agent_window_active(rq, now))
    prefer p->wake_cpu /* if not irq-hot, not deep-idle */

if (rq_agent_window_active(rq, time))
    util = max(util, rq->agent_min_util);

while (index > 0 &&
       drv->states[index].exit_latency > LIMIT_US)
    index--;  /* walk down to C1 or C0 */

The Budget Layer:
Safety Without Compromise

Any mechanism that keeps CPUs warm, limits deep idle, or prioritizes completions can be abused. If every process claims "I am latency-critical," the system loses fairness, power efficiency, and thermal headroom. The patch series addresses this directly with a cgroup token-bucket model — the last and most important piece of the design.

/* Called at each agent window arm — before granting the window. */
static bool agent_budget_check_and_debit(struct cgroup_agent_budget *bgt)
{
    u64 now = ktime_get_ns();
    u64 refill;

    /* Refill tokens based on elapsed time */
    refill = min((now - bgt->last_refill_ns) * bgt->refill_rate_per_ns,
                 bgt->max_tokens - bgt->tokens);
    bgt->tokens        += refill;
    bgt->last_refill_ns = now;

    if (bgt->tokens < bgt->cost_per_window)
        return false;  /* budget exhausted: degrade gracefully */

    bgt->tokens -= bgt->cost_per_window;
    return true;  /* budget available: grant full window */
}

This transforms the agent window from a hint into a bounded control system. A well-behaved agent with a moderate step rate maintains its full budget indefinitely. A misbehaving agent that tries to hold the CPU warm continuously depletes its tokens and is throttled to standard reactive policy — without affecting any other cgroup.

What Not
to Do

The easy solutions are blunt and dangerous. They improve a benchmark while degrading the system for everyone else, and they don't survive production deployment.

• Run the agent thread as SCHED_FIFO 99 — starves other tasks, produces priority inversion
• Use the performance governor globally — wastes 15–40% system power continuously
• Disable deep idle system-wide — destroys laptop battery life and server rack efficiency
• Mark every I/O request from the agent process as high-priority — background indexing becomes latency-critical
• Bypass Linux policy entirely (VFIO, bare-metal busy-poll) — loses all multi-tenant fairness

The correct model is the opposite of all of these:

• Specific signal — only agent threads that opt in via sched_setattr() with SCHED_FLAG_AGENT_LATENCY
• Narrow window — expires automatically; no manual disarming required
• Measurable effect — every decision point is instrumented with a tracepoint
• Budgeted enforcement — cgroup token bucket prevents sustained power override

A Practical
Six-Phase Plan

The patch series follows a deliberate order: measurement before policy. No optimization is proposed without first making the slowpath visible and attributable. This is the sequence:

Part 3 Needs
Data, Not Architecture

A credible Part 3 should not add more design. It should add numbers — answering the questions the design raises but cannot answer without empirical measurement:

/* How often does DVFS ramp occur after agent wakeups? */
/* How much wakeup-to-run latency is due to scheduler placement? */
/* How much deferred-completion delay comes from workqueues/timers? */
/* How often do page faults or VFS metadata lookups gate agent steps? */
/* How much does the cgroup budget reduce abuse while preserving p99? */
/* What is the energy cost of the agent window (Watts vs. baseline)? */

That is the line between a design note and a systems paper. The repo's docs/measurement-plan.md defines the experimental setup, eBPF collection methodology, and statistical requirements for each question. The selftest in selftests/agent_loop.c provides the controlled workload to answer them.

The new signal

The old optimization signal for kernel scheduling and power management was a single dimension: utilization. The signal the agentic kernel needs is three-dimensional:

/* old */
signal = utilization

/* new */
signal = {
    utilization,         /* what PELT measures today            */
    temporal_intent,     /* "I will wake again within window_ns" */
    budget,              /* "I have N tokens of latency credit"  */
}

Agentic workloads are the first mainstream workload class where temporal intent — the knowledge that a wakeup is not isolated but part of a recurring sequence — is both predictable and actionable. The kernel has always had utilization. What it has never had is a way to say: this CPU will be needed again soon, keep it ready, but stop when the loop does.