A Bounded Reclaim Actuator for PSI-Guided Compressed Memory: A Controlled Ablation

A Bounded Reclaim Actuator for PSI-Guided Compressed Memory: A Controlled Ablation Abhiyan Dhakal

Sanjog Sigdel✉

itsabhiyandhakal@gmail.com Department of Computer Science and Engineering, Kathmandu University Dhulikhel, Nepal

arXiv:2608.13689v1 [cs.OS] 13 Aug 2026

Abstract When the aggregate working set of active processes exceeds physical RAM capacity, the machine experiences memory pressure. Applications may therefore slow down before the kernel kills a process. Linux provides several ways to observe and respond: Pressure Stall Information (PSI) can detect memory-related task stalls, zram can provide compressed in-memory swap space, and cgroup v2 can request memory reclamation within a selected control group. These facilities are often discussed together even though they act at different points in the pressure path. This paper examines that distinction with a controlled systems study. We compare three setups: zram enabled from startup; zram enabled only after PSI indicates memory pressure; and zram enabled from startup with a one-time 96 MiB cgroup reclaim request. We first selected the request size in a 16-case pilot, then ran 180 confirmatory cases, 60 cases for each setup, on nine 1-vCPU Linux virtual machines with compute and SQLite workloads. Compared with static zram, the bounded reclaim configuration reduced compute p99 response time by 6%, while the SQLite result was statistically indistinguishable. Delayed activation had higher median p99 latency than both alternatives. These results suggest that the benefit depends on the foreground workload and its memory-access path, rather than a general improvement across workloads.

CCS Concepts • Software and its engineering → Virtual memory.

Keywords Memory Pressure, Pressure Stall Information (PSI), cgroup v2, zram, Proactive Memory Reclaim, Operating System

1

Introduction

Memory pressure is a condition in the operating system where the demand for random-access memory (RAM) approaches or exceeds the available physical memory. This forces the system to reclaim memory or use slower storage backed mechanisms such as swapping. A foreground request can spend time waiting for a page to be reclaimed, written to swap, or read back, even while the machine is still alive and making progress. For a user, it is a slow interaction. Compressed memory is attractive because it can make a small amount of physical memory behave like a larger tier. However, the compression backend does not decide which pages should leave the active set or when that work should happen [2, 4, 18, 21].

sanjog.sigdel@ku.edu.np Department of Computer Science and Engineering, Kathmandu University Dhulikhel, Nepal In Linux, Pressure Stall Information (PSI) reports time stalled while tasks wait for memory or other resources [13, 19]. zram provides a compressed block device that the kernel can use as swap [14]; zswap is a related compressed cache placed in front of a conventional swap device [15]. A control group is a Linux mechanism for placing processes in a hierarchy and applying resource limits and accounting to them. The cgroup v2 interface is the current unified version of that mechanism. Its memory.reclaim control file accepts a byte amount written by a user space program and asks the kernel to reclaim approximately that much memory from the selected cgroup [10]. The kernel retains control over page selection. This paper compares three configurations under the same memorypressure workload to inspect whether a user space program can use a sustained PSI signal to request bounded reclaim and improve foreground responsiveness when compressed swap is already available. First, zram is available from the beginning of the run. Second, zram is enabled only after a sustained PSI signal. Third, zram is available from the beginning and the same PSI signal triggers one 96 MiB reclaim request against the background cgroup.

2

Related Work

Compressed memory has been used to extend effective memory capacity and reduce access to slower storage [4, 18, 21]. Swapcompression studies similarly showed that compression can improve application performance when physical memory is insufficient [2]. More recent systems optimize lower memory tiers directly: ZNSwap co-designs swap with zoned storage, while STYX offloads zswap compression to a SmartNIC [1, 5]. These systems change storage placement or compression execution rather than the timing of a userspace reclaim request. Other systems protect interactive work by changing reclaim, page preparation, or writeback. Redline treats responsiveness as an explicit resource-management objective [22]. Acclaim studies reclaim and refault costs that affect Android applications, ASAP prepares pages before application switches, and SWAM revises mobile swap and out-of-memory policy [8, 9, 17]. PMR separates page shrinking from storage-friendly writeback, while Archer uses page associations to adapt compression for mobile response time [6, 7]. These systems make stronger choices about page identity or scheduling than the cgroup request evaluated here. Feedback-driven systems connect memory-pressure observations to repeated control decisions. TMO uses its Senpai userspace controller to monitor PSI and adjust memory offloading over time [20]. Hermit applies feedback-directed asynchrony to remote memory, PageFlex exposes userspace paging policies through eBPF, and DAMON and Multi-Gen LRU provide richer information about

Dhakal et al.

page access or recency [11, 12, 16, 23]. These systems demonstrate a broader range of feedback, paging, and page-selection policies than the intervention studied here.

3

Methodology

Each experimental case combined one configuration with the background pressure generator and both foreground workloads. Every case followed warmup, pressure, and recovery phases in the sequence shown in Figure 1.

3.1

Experimental Environment

The confirmatory experiment ran on qualified 1-vCPU, 1-GiB Linux VMs denoted vm0 through vm8. Before scheduling cases, qualification checked root access, the kernel and experiment configuration, a writable memory.reclaim interface, zram, a swapfile, available disk space, clean starting swap, and the source commit used for the campaign. Each case created sibling background and foreground cgroups. The background cgroup allocated and repeatedly touched memory to create pressure. The foreground cgroup ran the compute and SQLite workloads. The reclaim configuration targeted only the background cgroup, so the controller did not directly reclaim the foreground workloads’ memory. Table 1 summarizes the configuration held constant across the confirmatory cases. Table 1: Fixed configuration used in all confirmatory cases. Item

Value

Case phases Background memory Compressed swap

5-min warmup, 20-min pressure, 5-min recovery 384 MiB limit; 640 MiB target; 128 MiB active set LZO zram; 1-GiB device; 20% memory limit

3.2

Pressure and Foreground Workloads

The pressure generator generated an allocation larger than the background cgroup’s limit while repeatedly touching its active set. Earlier sensitivity tests showed that allocation rate changed the interval between PSI and material swap growth, while page contents changed zram occupancy and writeback [3]. The confirmatory design therefore crossed two representative allocation rates with structured and random contents, producing the four regimes in Table 2. Table 1 gives the settings held constant. The foreground cgroup ran two canaries, small periodic workloads used to observe latency during pressure. The compute canary maintained a hot memory region and performed memory touches and computation. The SQLite canary issued indexed point queries against an 80,000-row database with 1,536-byte payloads; SQLite ran as an embedded library inside the canary process rather than as a separate server. Both canaries ran every 100 ms and recorded the scheduled start, actual wake time, and completion time. Wake delay is the interval from scheduled start until execution begins, while service time is the interval from that point until completion. Each trace also recorded deadline misses, faults, and context switches. A deadline miss occurred when a request did not complete before its next 100 ms period.

3.3

Configurations and PSI Trigger

The static-zram configuration enabled the fixed backend before the case began and performed no controller action. The delayedactivation configuration began with that backend inactive and enabled it once after the trigger. The bounded-reclaim configuration enabled the backend before the case began and wrote 96 MiB once to the background cgroup’s memory.reclaim file after the trigger. Linux memory PSI distinguishes two stall states. The some state accumulates time during which at least one non-idle task in the monitored cgroup is stalled on memory, whereas full accumulates time during which all non-idle tasks are stalled simultaneously. Linux maintains a cumulative total counter for each state in microseconds [13]. The two triggered configurations used the same predicate. The controller read the background cgroup’s PSI counters in one-second windows and required the some total counter to increase by at least 1 ms in each of three consecutive windows. It then performed the action assigned to the configuration; static zram had no trigger action.

3.4

Pilot Dose Selection

The pilot selected the reclaim amount before the confirmatory schedule was generated. It ran on vm0 with a 2-minute warmup, 5minute pressure phase, and 2-minute recovery. The four candidate requests, 16, 32, 64, and 96 MiB, were each tested in the four pressure regimes, giving 16 pilot cases. A dose was eligible only if all four requests completed within one second, produced no OOM or interface error, achieved at least 80% of the requested amount computed as pgsteal times the page size, and left valid backend and restoration telemetry. Table 3 reports the worst duration and minimum achieved/requested ratio observed for each dose. All four doses passed, so the predefined rule selected the largest eligible request, 96 MiB.

3.5

Confirmatory Schedule

The confirmatory dataset contains 60 matched triplets, each containing one case per configuration under the same VM, pressure regime, and repeat identifier. These triplets produced 180 cases. Every case retained its original outcome. A case could be rerun only after an infrastructure failure, not after an OOM, failed reclaim, partial reclaim, or unfavorable latency result.

3.6

Statistical Analysis

The two primary outcomes were pressure-phase p99 response time for the compute and SQLite workloads. For each workload, bounded reclaim was compared with static zram and delayed activation, giving four primary comparisons. Using the matched triplets, the analysis computed the logarithm of each reclaim-to-comparator response-time ratio and resampled repeats within each VM, regime stratum. Strata received equal weight before the estimate was transformed back to a ratio; values below one favor bounded reclaim. Each primary comparison reports a simultaneous 98.75% bootstrap interval. This interval is an uncertainty range for the ratio, and the simultaneous level is chosen so that the four intervals together have a 95% family-wise target rather than treating four separate tests as unrelated. The predefined rule required all four

A Bounded Reclaim Actuator for PSI-Guided Compressed Memory: A Controlled Ablation

Figure 1: Shared case timeline with configuration-specific actions at a case-dependent trigger. Table 2: The four pressure regimes used in the confirmatory study. Regime

Allocation step

Nominal rate

Page contents

Moderate/structured Moderate/random Gradual/structured Gradual/random

16 MiB every 200 ms 16 MiB every 200 ms 16 MiB every 1 s 16 MiB every 1 s

80 MiB/s 80 MiB/s 16 MiB/s 16 MiB/s

Compressible structured bytes Low-compressibility random bytes Compressible structured bytes Low-compressibility random bytes

Table 3: Pilot results used to select the 96 MiB reclaim request. Dose 16 MiB 32 MiB 64 MiB 96 MiB

Max. duration

Min. achieved/requested

Errors

Decision

73.6 ms 51.5 ms 118.5 ms 164.4 ms

1.0010 1.0000 1.0003 1.0009

0 0 0 0

Eligible Eligible Eligible Selected

upper bounds to be below one and all four point estimates to show at least a 5% reduction before claiming a general responsiveness benefit. An interval entirely above one indicated harm for that comparison. Absolute p95 and p99 differences, wake and service time, deadline misses, PSI, refaults, swap, zram, and reclaim execution were secondary measurements. An absolute difference is the latency in one configuration minus the latency in the other, in microseconds; it complements the scale-free ratio by showing the size of the change in the observed units.

4

Evaluation

All scheduled confirmatory cases were available for analysis, and no primary comparison had a missing outcome. Figure 2 summarizes the four primary response-time ratios. All 60 bounded-reclaim requests completed successfully, with a median duration of 131.5 ms, p95 duration of 178.7 ms, and a minimum achieved/requested ratio of 1.0000.

4.1

Foreground Response Time

Table 4 reports the four primary comparisons. For the compute workload, the reclaim-to-static ratio was 0.938 with interval [0.906, 0.971], corresponding to an estimated 6.2% reduction in p99 response time. The reclaim-to-delayed-activation ratio was 0.704 [0.675, 0.735], also favoring reclaim.

Nominal allocation time 8s 8s 40 s 40 s

For SQLite, reclaim improved p99 relative to delayed activation: the ratio was 0.765 [0.726, 0.806]. The comparison with static zram was 0.993 [0.968, 1.020]. Because this interval includes one, the data do not show a clear SQLite difference between those two configurations. The predefined all-four rule therefore reports no general responsiveness benefit and no detected harm.

4.2

Wake and Service Time

Table 5 separates the case-level wake and service measurements across the 60 cases in each configuration. Delayed activation’s larger response times coincided with larger wake-delay medians. Bounded reclaim did not reduce every component relative to static zram: for example, its median compute and SQLite wake p99 values were slightly higher. The compute improvement therefore should not be described as a uniform speedup of every timing component. Deadline misses were rare in all three configurations. This controlled workload can expose tail differences, but the low miss counts do not establish that any configuration would protect deadlines for a larger interactive application.

4.3

Pressure and Memory Behavior

The mechanism measurements describe how each configuration changed the pressure episode. Median accumulated some stall time and full stall time were 1.342 s and 1.114 s with bounded reclaim, 1.515 s and 1.306 s with delayed activation, and 1.818 s and 1.730 s with static zram. Median refault counts were 32,786, 32,905, and 34,104, respectively. Median swap-out was also close for bounded reclaim and static zram (99,027 and 99,198 KiB), while delayed activation reached 103,028 KiB and showed the expected late growth in zram occupancy after its backend was enabled. These counters explain system behavior but do not replace the foreground measurements. A PSI reduction shows that the pressure path changed, and a completed reclaim request shows that the kernel performed work, but neither proves that a particular foreground

Dhakal et al.

Figure 2: Prespecified pressure-phase p99 ratios for bounded reclaim versus the two comparison configurations. Table 4: Primary p99 comparisons between bounded reclaim and the two alternatives. Workload

Comparison

Ratio

Lower

Upper

Median absolute difference (𝜇s)

Compute Compute SQLite SQLite

Reclaim/static Reclaim/delayed activation Reclaim/static Reclaim/delayed activation

0.938 0.704 0.993 0.765

0.906 0.675 0.968 0.726

0.971 0.735 1.020 0.806

-12.5 -384.5 +36.5 -380.0

Table 5: Foreground latency and deadline misses under each configuration. Configuration

Compute p95 (𝜇s)

Compute p99 (𝜇s)

Compute wake p99 (𝜇s)

SQLite p95 (𝜇s)

SQLite p99 (𝜇s)

SQLite wake p99 (𝜇s)

Deadline misses

373.5 482.0 369.0

943.0 1337.5 921.0

778.5 1187.0 792.0

859.5 1081.0 864.5

1574.0 2008.5 1631.5

794.5 1247.0 813.5

3 4 3

Static zram Delayed activation Bounded reclaim

workload benefited. The SQLite/static comparison demonstrates this distinction: the mechanism executed successfully without producing a clear p99 improvement for that workload.

4.4

Variation Across Pressure Regimes

Table 6 reports descriptive case-level medians for each treatment within each pressure regime; each cell summarizes 15 cases. The values expose the workload dependence hidden by an overall median: bounded reclaim was not the lowest treatment in every cell. These unpaired medians describe the cells; the prespecified paired analysis in Table 4 determines the primary conclusions. Delayed activation had the highest median p99 in every regime, while bounded reclaim alternated with static zram depending on workload and regime. Table 6: Foreground p99 across workloads and pressure regimes. Compute p99 (𝜇s)

SQLite p99 (𝜇s)

Regime

Static

Act.

Reclaim

Static

Act.

Reclaim

Moderate/structured Moderate/random Gradual/structured Gradual/random

1,044 908 895 927

1,440 1,290 1,249 1,339

1,014 1,002 911 775

1,727 1,533 1,372 1,495

2,184 1,901 1,916 2,014

1,697 1,724 1,666 1,485

5

Limitations

The homogeneous 1-vCPU experimental population reduces configuration variation and supports paired comparisons, but it does not represent larger servers, desktop systems, mobile devices, or heterogeneous production fleets. The reported intervals describe this population rather than all Linux systems. The background allocator was designed to produce repeatable pressure, and the two foreground workloads were designed to expose wake and service delays. They do not reproduce the full behavior of an interactive desktop, database server, or distributed application. The difference between the compute and SQLite results is consistent with workload-dependent memory access, but the experiment does not identify every cause of that difference. The study evaluated only the pilot-selected request and issued it once. That fixed action may not be appropriate for other memory sizes or workloads. The experiment does not test adaptive doses, repeated feedback, or a controller that changes its action as pressure evolves. Because victim selection remained under kernel control, the request and mechanism counters cannot show which pages created the later latency behavior. Establishing that causal path would require additional page-level tracing or an intervention that controls victim selection. The three-configuration comparison does not establish performance against the complete policies reviewed in Section 2. Five

A Bounded Reclaim Actuator for PSI-Guided Compressed Memory: A Controlled Ablation

repeat identifiers per regime also limit stratum-specific precision. Finally, the inconclusive SQLite/static interval is not evidence that the configurations are equivalent; it means that this study did not detect a difference under the predefined test.

6

Conclusion

This study compared static zram, delayed activation, and bounded reclaim using compute and SQLite foreground canaries. Delayed activation had the highest descriptive median p99 for both workloads. Bounded reclaim reduced compute p99 relative to static zram and reduced both workloads’ p99 relative to delayed activation. It did not produce a clear SQLite improvement over static zram, so the predefined decision rule did not establish a general responsiveness benefit. The workload-dependent result motivates adaptive repeated control, broader workloads and machine sizes, page-protection or victim-selection mechanisms, and further study of proactive reclaim and writeback.

References [1] Shai Bergman, Niklas Cassel, Matias Bjørling, and Mark Silberstein. 2022. ZNSwap: un-Block your Swap. In 2022 USENIX Annual Technical Conference. USENIX Association, 1–18. https://www.usenix.org/conference/atc22/presentation/ bergman [2] Raul Cervera, Toni Cortes, and Yolanda Becerra. 1999. Improving Application Performance through Swap Compression. In 1999 USENIX Annual Technical Conference. USENIX Association. https://www.usenix.org/conference/1999usenix-annual-technical-conference/improving-application-performancethrough-swap [3] Abhiyan Dhakal. 2026. Predicomp: PSI-Guided zram Activation Case Study Dataset. Published dataset; version 1 contains 12 checksum-indexed activationstudy archives. doi:10.5281/zenodo.21619558 [4] Fred Douglis. 1993. The Compression Cache: Using On-line Compression to Extend Physical Memory. In USENIX Winter 1993 Conference. USENIX Association, San Diego, CA. https://www.usenix.org/conference/usenix-winter-1993conference/compression-cache-using-line-compression-extend-physical [5] Houxiang Ji, Mark Mansi, Yan Sun, Yifan Yuan, Jinghan Huang, Reese Kuper, Michael M. Swift, and Nam Sung Kim. 2023. STYX: Exploiting SmartNIC Capability to Reduce Datacenter Memory Tax. In 2023 USENIX Annual Technical Conference. USENIX Association, 619–633. https://www.usenix.org/conference/ atc23/presentation/ji [6] Changlong Li, Zongwei Zhu, Chao Wang, Fangming Liu, Fei Xu, Edwin H. M. Sha, and Xuehai Zhou. 2025. Archer: Adaptive Memory Compression with Page-Association-Rule Awareness for High-Speed Response of Mobile Devices. In 23rd USENIX Conference on File and Storage Technologies. USENIX Association, 497–511. https://www.usenix.org/conference/fast25/presentation/li [7] Wentong Li, Li-Pin Chang, Yu Mao, and Liang Shi. 2025. PMR: Fast Application Response via Parallel Memory Reclaim on Mobile Devices. In 2025 USENIX Annual Technical Conference. USENIX Association, 1569–1584. https://www. usenix.org/conference/atc25/presentation/li-wentong [8] Yu Liang, Jinheng Li, Rachata Ausavarungnirun, Riwei Pan, Liang Shi, Tei-Wei Kuo, and Chun Jason Xue. 2020. Acclaim: Adaptive Memory Reclaim to Improve User Experience in Android Systems. In 2020 USENIX Annual Technical Conference. USENIX Association, 897–910. https://www.usenix.org/conference/atc20/ presentation/liang-yu [9] Geunsik Lim, Donghyun Kang, MyungJoo Ham, and Young Ik Eom. 2023. SWAM: Revisiting Swap and OOMK for Improving Application Responsiveness on Mobile Devices. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking. Association for Computing Machinery, 224–238. doi:10.1145/3570361.3592518 [10] Linux Kernel Documentation. 2026. Control Group v2. Accessed 2026-07-31. https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html [11] Linux Kernel Documentation. 2026. DAMON-based Reclamation. Accessed 2026-07-31. https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/ reclaim.html [12] Linux Kernel Documentation. 2026. Multi-Gen LRU. Accessed 2026-07-31. https: //docs.kernel.org/mm/multigen_lru.html [13] Linux Kernel Documentation. 2026. PSI – Pressure Stall Information. Accessed 2026-07-31. https://www.kernel.org/doc/html/latest/accounting/psi.html

[14] Linux Kernel Documentation. 2026. zram: Compressed RAM-based Block Devices. Accessed 2026-07-31. https://www.kernel.org/doc/html/latest/admin-guide/ blockdev/zram.html [15] Linux Kernel Documentation. 2026. zswap. Accessed 2026-07-31. https://www. kernel.org/doc/html/latest/admin-guide/mm/zswap.html [16] Yifan Qiao, Chenxi Wang, Zhenyuan Ruan, Adam Belay, Qingda Lu, Yiying Zhang, Miryung Kim, and Guoqing Harry Xu. 2023. Hermit: Low-Latency, High-Throughput, and Transparent Remote Memory via Feedback-Directed Asynchrony. In 20th USENIX Symposium on Networked Systems Design and Implementation. USENIX Association, 181–198. https://www.usenix.org/conference/ nsdi23/presentation/qiao [17] Sam Son, Seung Yul Lee, Yunho Jin, Jonghyun Bae, Jinkyu Jeong, Tae Jun Ham, Jae W. Lee, and Hongil Yoon. 2021. ASAP: Fast Mobile Application Switch via Adaptive Prepaging. In 2021 USENIX Annual Technical Conference. USENIX Association, 365–380. https://www.usenix.org/conference/atc21/presentation/ son [18] Irina Chihaia Tuduce and Thomas Gross. 2005. Adaptive Main Memory Compression. In 2005 USENIX Annual Technical Conference. USENIX Association, Anaheim, CA, 237–250. https://www.usenix.org/conference/2005-usenix-annualtechnical-conference/adaptive-main-memory-compression [19] Johannes Weiner. 2018. Pressure Stall Information. Linux kernel documentation and upstream implementation. https://www.kernel.org/doc/html/latest/ accounting/psi.html [20] Johannes Weiner, Niket Agarwal, Dan Schatzberg, Leon Yang, Hao Wang, Blaise Sanouillet, Bikash Sharma, Tejun Heo, Mayank Jain, Chunqiang Tang, and Dimitrios Skarlatos. 2022. TMO: Transparent Memory Offloading in Datacenters. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’22). 609–621. doi:10.1145/3503222.3507731 [21] Paul R. Wilson, Scott F. Kaplan, and Yannis Smaragdakis. 1999. The Case for Compressed Caching in Virtual Memory Systems. In 1999 USENIX Annual Technical Conference. USENIX Association, 101–116. https://www.usenix.org/legacy/ event/usenix99/full_papers/wilson/wilson_html/index.html [22] Ting Yang, Tongping Liu, Emery D. Berger, Scott F. Kaplan, and J. Eliot B. Moss. 2008. Redline: First Class Support for Interactivity in Commodity Operating Systems. In Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation. USENIX Association, 73–86. https://www.usenix. org/legacy/event/osdi08/tech/full_papers/yang/yang_html/ [23] Anil Yelam, Kan Wu, Zhiyuan Guo, Suli Yang, Rajath Shashidhara, Wei Xu, Stanko Novaković, Alex C. Snoeren, and Kimberly Keeton. 2025. PageFlex: Flexible and Efficient User-space Delegation of Linux Paging Policies with eBPF. In 2025 USENIX Annual Technical Conference. USENIX Association, 291–306. https://www.usenix.org/conference/atc25/presentation/yelam

Related documents

• ADAPTIVE CONTROL LAW FOR ACTIVE FLUTTER SUPPRESSION IN PRESENCE OF ACTUATION FAILURE#369397
• Quantum-optical reset with classical memory#927153
• On sparsity and directional forgetting in adaptive control#1050121
• Output regulation of nonlinear systems based on backstepping-techniques#69949
• Plaintext Recovery Against Post-Filtering Access Control#447883