Compressed memory is attractive because it offers another way to work within limited RAM. Instead of immediately treating every displaced page as a storage operation, a system can keep some data in a smaller representation. The benefit depends on what the data looks like and what the compression work costs.
On Linux, zram and zswap address this area through different mechanisms. They are not interchangeable names, and enabling both does not automatically combine their benefits. This guide explains the distinction, then shows how to evaluate a compressed-memory configuration as a workload decision rather than a promise of free extra RAM.
Start with the shared principle
Compression represents some data using fewer bytes than its uncompressed form. Doing that work consumes processing resources, and not all data shrinks equally. A workload full of already compressed or otherwise difficult-to-compress data can behave differently from one with highly repetitive contents.
For planning purposes, treat any effective-capacity gain as measured behavior, not as a guaranteed multiplier. If a demonstration shows a favorable ratio for one input, that does not establish the same ratio for your browser session, database, build, or model-serving process.
The Mem Swap fundamentals page provides the broader context: memory management is about which data needs to remain readily available, which data can be moved or reconstructed, and what delays the workload can tolerate.
zram presents a compressed block device
zram creates a RAM-backed block device that stores data in compressed form. A common use is to configure that device as swap. In that arrangement, the logical swap capacity and the actual physical RAM consumed by the compressed contents are not the same quantity.
That distinction is important when interpreting a dashboard. A large configured zram device does not mean that the machine has gained that much physical RAM. Actual memory use depends on stored data and implementation overhead. A capacity plan must leave room for the active workload and the compressed representation itself.
Some zram configurations support writeback to a backing device. That is an additional feature with its own requirements, not a reason to assume that every zram installation has disk spillover. Inspect the installed system rather than generalizing from the word “zram” alone.
zswap is a compressed cache for swap pages
zswap sits in front of a backing swap area and attempts to retain pages in a compressed memory pool. It is not itself a replacement swap block device. Its design includes a path for pages to reach the backing swap device when necessary.
The Linux kernel's zswap documentation describes this compressed-cache role and the backing-store relationship. It is the key distinction to retain when comparing zswap with a zram device configured directly as swap.
The practical question is therefore not just “Which compresses memory?” Both involve compression, but they fit into different storage arrangements. Establish which components exist, where pages can go, and which component owns each reported number before attempting to compare outcomes.
Inspect what the distribution already provides
Begin with swapon --show to identify active swap areas. Where the tools are available, zramctl can help inspect zram devices. Configuration files, boot parameters, and distribution services may provide additional information about how the arrangement is created.
Do not assume that installing a tool activates the underlying feature, or that the presence of a device proves that it is being used as swap. Verify the runtime state. Similarly, an enabled setting is not a measurement of the benefit achieved by the current workload.
Keep a brief inventory: physical RAM, active swap areas, backing storage, compression configuration, operating-system version, and the service or tool that manages the setup. That inventory prevents a later administrator from unknowingly stacking a second policy over the first.
Compare the arrangement, not a feature name
A useful experiment describes complete configurations. “Current distribution default” versus “a specific zram setup with a stated size and algorithm” is testable. “zram versus normal memory” is too vague to reproduce because it leaves too many mechanisms unspecified.
Use the same application workload and the same input. Record task completion time, user-visible pauses, failures, CPU activity, memory pressure, and storage behavior where relevant. The goal is to see whether the new arrangement improves useful work, not simply whether a compression counter increases.
Distinguish the first run from later runs. Startup, application caches, and other background work can change the demand pattern. A fair comparison should either control those conditions or clearly state how they differed.
Build a representative test session
For a laptop, a realistic session might include a browser, an editor, and the actual application that triggers the slowdown. For a build machine, use a representative project and worker count. For a service, exercise expected concurrency and input sizes within an authorized test environment.
Define a stopping condition before creating severe pressure. Save work and avoid conducting an uncontrolled exhaustion test on a machine that is serving other users. A repeatable moderate test is more useful than a dramatic freeze that destroys the evidence you hoped to collect.
Understand the CPU-versus-memory trade-off
A compressed arrangement may reduce the need for some storage access, but it introduces work to compress and decompress data. Whether that trade is useful depends on the machine and the pattern of access. A CPU-constrained workload may respond differently from one with spare processing capacity.
Do not judge this by the presence of additional CPU activity alone. Extra work can still be worthwhile if the important task completes sooner or becomes more responsive. Conversely, a favorable compression ratio is not enough if the added processing causes the workload to miss its objective.
Think in terms of the whole task. The relevant question is “Did the intended work improve under comparable conditions?” A subsystem metric is evidence toward that answer, not the answer itself.
Be cautious about combining layers
Putting multiple compression mechanisms into one memory path can add complexity without a demonstrated benefit. The exact behavior depends on the configuration, so there is no universal rule that every combination is harmful or helpful. The responsible approach is to know why each layer is present.
Start from a documented, understandable baseline and change one mechanism at a time. Record how the backing arrangement changes and whether monitoring still distinguishes physical usage, logical capacity, and storage traffic. If a graph becomes difficult to interpret after a change, improve the observation before drawing conclusions.
Our Linux swappiness guide covers a related but separate control. Do not assume that the same swappiness hypothesis applies unchanged when you replace storage-backed swap with a compressed memory-backed arrangement.
Include operational requirements in the choice
Consider startup configuration, observability, recovery, and the distribution's maintenance tools. A configuration that is easy to reproduce and inspect may be preferable to an elaborate experiment that only one administrator understands. Document the ownership and the steps needed to restore the previous state.
Laptop hibernation requires special attention. Do not assume that a volatile compressed-memory device by itself provides a suitable persistent resume image. Verify the distribution's hibernation requirements separately, including the backing storage and encryption arrangement.
For cloud or container workloads, confirm which system actually controls the mechanism. A container user may observe pressure without permission to change host swap configuration. The cloud memory swap overview explains why host and workload limits must be considered separately.
Conclusion: compression is a measured trade-off
zram and zswap provide different ways to incorporate compressed memory into Linux memory management. Their usefulness cannot be decided from a brand-like feature name, a nominal device size, or a compression ratio taken from someone else's workload.
Inspect the current system, compare complete configurations, and measure the task that matters. Keep the arrangement that delivers an acceptable balance of responsiveness, completion time, capacity, and maintainability. Compression is a tool for managing pressure, not a substitute for understanding why the pressure exists.
