News › performance
By The Linux Camp News, October 7, 2026
Usama Arif’s two-patch proposal separates zswap compression and decompression requests, then bypasses a load-side lock for software compressors. His VM tests show shorter worst-read delays, but production gains and release availability remain unestablished.
Usama Arif submitted two Linux zswap patches on October 5, 2026, at 17:22 PDT, October 6 in UTC, to reduce contention when reading cached swap pages. Phoronix’s October 6 report described the series as under review. The sources retrieved October 7 establish a proposal and author-reported benchmark improvements, not a merged kernel change or distribution release. 2 1
Zswap is a compressed RAM cache for swap pages. The targeted delay comes from scheduling around a shared lock, rather than the compression algorithm’s speed. Stores and loads share a per-CPU compression request and mutex, a lock that serializes access. A low-priority store can stop running after releasing the compressor’s internal stream lock while still holding zswap’s mutex. A higher-priority reader then cannot proceed until that store gets CPU time again, even though the compressor has released its own lock. 1 3
The first patch gives compression and decompression separate requests, completion waits and mutexes. This removes their shared zswap request lock, but readers can still queue behind other readers. The underlying per-CPU crypto transform remains shared: Arif says in-tree implementations do not modify its state during compression or decompression, while shared codec state has separate locking. 3
The second patch addresses reader-to-reader contention by putting each eligible decompression request on the calling task’s stack instead of sharing a per-CPU request. Eligibility requires a synchronous algorithm with no extra request context; Arif says all in-tree software compressors qualify. Asynchronous algorithms and synchronous implementations needing that context retain the per-CPU request and mutex. This is therefore a conditional removal of zswap locking, not a universal lock-free decompression path. 4
Arif reports that the median of each run’s slowest read fell from 22.3 to 0.97 milliseconds with one vCPU, and from 314 to 7.0 milliseconds with eight vCPUs. These are worst-read measurements aggregated across runs, not average read latency or throughput. The patched eight-vCPU results still ranged from 5.0 to 98 milliseconds, so even this controlled test did not eliminate long outliers. 2 1
The benchmark deliberately stresses priority differences: lower-priority workers page memory out and read it back, normal-priority tasks spin, and higher-priority readers measure access delays. Each of five runs lasted 12 seconds in a zstd VM with lazy preemption, vm.page-cluster=0 and RAM-backed swap. Those conditions limit extrapolation: the supplied results do not establish production gains with disk-backed swap, other compressors or other preemption modes. 2
The operational inference is that this proposal matters most when latency-sensitive readers compete with lower-priority paging work. For evaluation, check the compressor type, preemption configuration and whether stalls occur on reads or stores, because those distinctions determine which waits the patches address. Arif explicitly leaves store-to-store serialization unresolved, including direct reclaim and MADV_PAGEOUT. On PREEMPT_RT, a load can also still wait behind a preempted store inside the codec’s stream lock. 4 2
The proposed trade-off is additional context and stack space. For software compressors, the complete series keeps the previous number of allocated requests but adds 72 bytes to each per-CPU context. Arif estimates approximately 270 bytes of additional load-path stack depth on x86-64; asynchronous algorithms incur that stack cost too, despite retaining their request mutex. 2 4