Understand where the pages go
Linux documents zswap as a compressed RAM cache for pages being swapped, backed by a swap device. It exchanges processor work for potentially less storage I/O. That mechanism is different from adding physical memory, and it should enter a build discussion as a tradeoff. Before changing it, establish whether the application’s problem is a brief allocation peak, continuous oversubscription or an unrelated delay. Each situation can justify a different response, even when all three appear on a small computer.
Watch the task, not just the total
A smaller amount of swap traffic is useful only in relation to the application’s required behaviour. Keep response time, error count and administrative access in the observation set. Compression can consume processing resources needed elsewhere in the pipeline. Conversely, a short-lived pressure event may be tolerable if the service remains usable. The decision should describe the accepted operating behaviour rather than declaring every swap allocation a failure or treating a low write count as success by itself.
Read pressure as time lost
The kernel’s Pressure Stall Information interface reports resource-related stalls for CPU, memory and I/O. Use it alongside the application timeline to see whether a change reduces waiting or merely moves it. Retain the same request set and background services across comparisons. A busy percentage cannot explain why a user waited, while a pressure signal alone cannot identify which application choice created that wait. The combination can narrow the next experiment without pretending to provide a complete diagnosis.
Keep a capacity decision available
If normal requests repeatedly push the system into unacceptable delays, revisit model size, accepted context, concurrency or other resident services. Do not make compression the only permitted solution. Record the kernel configuration and swap arrangement because availability and defaults vary between images. A useful conclusion might be to retain zswap for occasional peaks while imposing a smaller request limit. Another might be to remove the oversized workload. Either is a clearer engineering decision than an undocumented tuning change.
Sources & publication notes
Retrospective period: August 2025. Written and published November 2, 2026. Product announcements establish release timing; support pages are linked as current references.