research log
From PSI signal validation to a cgroup-scoped policy screen
The long-term question behind this work is practical: can memory-management policy keep a constrained machine responsive? It is tempting to begin by implementing a controller and comparing performance. That would put the policy ahead of the evidence needed to justify it.
Origin question
Can Linux Pressure Stall Information identify early, repeatable pressure windows before reclaim and swap activity dominate?
This began as a narrower question than whether a particular policy improves performance. The first task was to establish whether the proposed input to such a policy was timely and stable enough to be useful at all.
Experimental context
The harness runs fixed workloads under controlled memory limits and records rolling PSI windows alongside memory availability, reclaim counters, page faults, swap, zswap, zram, cgroup observations, and phase-aligned responsiveness timing. Runs use stable raw JSONL output, and failed runs are retained rather than silently removed.
Workload compressibility is an explicit control. A policy can appear effective because the workload compresses well, not because its pressure response is generally useful. Disk-backed swap and zswap must also be treated as different experimental conditions.
Evidence to date
Controlled V1 and V2 reruns established that the measured PSI counter becomes observable before material swap-slot growth under the tested workloads. The available lead time changes with the pressure ramp and memory configuration; it is not treated as a universal constant.
The original aggregate latency probe was not a valid responsiveness outcome. A replacement canary separates wake delay, service time, and end-to-end response on a monotonic schedule. Under pressure, it records worsening response and service-time tails rather than the misleading improvement reported by the original aggregate probe.
Compression-sensitivity work also confirmed that page content matters: structured and sparse pages occupy zswap very differently from random pages. Those results characterize the compression path; they do not themselves show a policy advantage.
Decision
The first milestone was signal characterization. The evidence needed three properties:
- temporal ordering: whether pressure signals appear before the system is already dominated by reclaim or swap;
- repeatability: whether that ordering survives repeated runs under the same workload definition; and
- workload sensitivity: whether the signal changes in understandable ways across memory limits and compressibility modes.
An isolated early PSI reading is not a policy result. The validation work established enough observable signal to justify a bounded policy screen, not a claim that PSI alone prescribes an optimal action.
Current policy screen
The active experiment uses separate foreground and background cgroups. A 384 MiB memory boundary makes background pressure attributable to the cgroup, while the foreground canary remains outside that cap. The controller observes only sustained background-cgroup PSI-some over one-second windows and activates zram once when a threshold-and-hold predicate qualifies. PSI-full remains diagnostic telemetry.
The screen compares disk swap, static zswap, static zram, and guided zram across structured and random workloads. It evaluates phase-aligned response and service-time tails, deadline misses, swap growth, backend occupancy, faults, reclaim, and valid no-trigger cases.
This screen is underway. It does not yet establish that guided zram improves responsiveness or outperforms static backends.
What changes next
Once the policy screen completes, its results can determine whether repeated bounded intervention, cooldown and hysteresis, or a cooperative cold-page compression path are justified. Those are follow-up designs, not current outcome claims.
If the screen does not show a useful policy effect, that is also a useful result. It would narrow the role PSI can play, motivate different features or sampling windows, or rule out this controller design before more machinery is built around it.
Limitations
Memory PSI reports aggregate time tasks spend stalled because of memory pressure; it does not identify the cause of every latency event or prescribe an action. Aggregate pressure can also hide workload-specific effects. The current experiments therefore treat PSI as one signal alongside reclaim, faults, swap activity, memory availability, and workload observations.