The Renaissance of zram: Why Compressed RAM Swap Is Relevant Again

I first touched zram in the early Android custom ROM era, when devices shipped with only 128 MB RAM. Back then, every MB counted, and zram could make the difference between a usable phone and constant app kills.

Then RAM became cheaper and bigger, and zram slowly faded out of mainstream tuning guides.

Now we are in an interesting phase again: memory prices have increased, many people keep hardware longer, and modern software keeps getting heavier. That makes zram worth revisiting.

---

🧠 What Is zram?

zram is a Linux kernel feature that creates a compressed block device in RAM. The most common use is to configure it as swap.

Instead of swapping memory pages to a slow disk, the kernel can place compressed pages into zram.

In simple terms:

• Without zram: swapped pages go to SSD/HDD
• With zram: swapped pages are compressed and kept in RAM

This trades some CPU time for much lower I/O latency and can improve responsiveness under memory pressure.

Side note: this idea is not Linux-only. macOS has used memory compression for years, and you can see it in Activity Monitor as the Compressed value in the Memory section.

How It Works Internally (High Level)

1. The kernel decides to evict less-used memory pages.
2. If zram swap is available, pages are compressed (for example with zstd or lz4).
3. Compressed pages are stored inside the zram device.
4. When needed again, pages are decompressed and restored.

Important detail: zram “disk size” is the uncompressed logical size. Physical RAM usage is lower, depending on compression ratio and metadata overhead.

---

✅ Pros and ❌ Cons

Pros

• Faster than disk swap in most scenarios
• Reduces swap writes to SSD/HDD
• Can improve desktop responsiveness under pressure
• Useful for low-memory VMs, laptops, and small home servers
• Easy to enable and test

Cons

• Uses CPU cycles for compression/decompression
• Does not create real extra RAM out of thin air
• Can hurt very CPU-constrained systems
• Not suitable as hibernation target
• If badly sized/tuned, benefits may be small

---

📌 When zram Makes Sense (and When Not)

Good Fits

• Older laptops/desktops with 4-8 GB RAM
• Small cloud VMs where adding RAM is expensive
• Build/dev environments with occasional memory spikes
• Home server workloads with short bursts (containers, light services)

Usually Not a Great Fit

• Systems already having plenty of RAM for the workload (for example 64+ GB with low utilization)
• CPU-bound workloads where every CPU cycle matters
• Heavy sustained swapping caused by fundamentally undersized memory

Rule of thumb: zram helps most with temporary pressure, not with a permanently memory-starved system.

---

📊 Quick Comparison: zram vs zswap vs Disk Swap

Option	Disk swap needed	Hibernate	Best fit
zram	No	No	Low RAM, bursty load
zswap	Yes	Yes	Existing disk swap
Disk swap	Yes	Yes	Simple, predictable setups

Short version:

• zram: fastest under pressure, but uses RAM for compressed pages.
• zswap: a compressed RAM cache in front of disk swap; useful if you already keep swap on disk.
• Disk swap: simplest option, but usually the slowest once memory pressure gets real.

In many practical desktop and small-server scenarios, zram is the easiest high-impact option.

Quick Decision Flow

1. Need reliable hibernation to disk? Use classic disk swap (optionally with zswap), not zram-only swap.
2. No hibernation, but frequent short memory spikes and responsiveness issues? Start with zram.
3. Already have disk swap and want to reduce write amplification with minimal layout changes? Consider zswap first.
4. Workload is CPU-bound and swap rarely used? Keep it simple and stay with classic swap.
5. Unsure? Enable zram with conservative sizing (25-50%), monitor for a week, then decide based on real usage.

---

Ubuntu Setup Tutorial

For Ubuntu, zram-tools is simple and available in current LTS releases.

1) Install

sudo apt update
sudo apt install zram-tools

2) Configure Size and Algorithm

Edit:

sudo nano /etc/default/zramswap

Example config:

ALGO=zstd
PERCENT=33
PRIORITY=100

• PERCENT=33 is a conservative starting point when your system also relies heavily on tmpfs and page cache
• ALGO=zstd is a good balanced default on modern CPUs

If your workload is light on tmpfs usage, you can test PERCENT=50 later.

3) Enable and Start

sudo systemctl enable --now zramswap.service

4) Verify

swapon --show
zramctl
free -h

You should see /dev/zram0 as active swap.

---

openSUSE Setup Tutorial

On openSUSE, zram-generator is a clean modern method (especially on Tumbleweed).

1) Install

sudo zypper refresh
sudo zypper install zram-generator

2) Create Configuration

Create:

sudo nano /etc/systemd/zram-generator.conf

Example:

[zram0]
zram-size = min(ram / 2, 4096)
compression-algorithm = zstd
swap-priority = 100
fs-type = swap

This follows a common conservative baseline used by modern distro defaults: 50% of RAM with a 4 GiB cap.

If your workload is tmpfs-heavy (for example browser-heavy sessions, container builds, or large /tmp usage), start with:

zram-size = min(ram / 3, 4096)

3) Apply and Start

sudo systemctl daemon-reload
sudo systemctl start systemd-zram-setup@zram0.service

4) Verify

swapon --show
zramctl

If zram-generator is not available in your repo setup, check systemd-zram-service as an alternative package.

---

Suggested Starting Values

• Baseline used by many defaults: min(ram / 2, 4096)
• If tmpfs/page cache pressure is high: start with 25-33% instead of 50%
• RAM <= 8 GB: usually 33-50% works well
• RAM 16-32 GB: usually 25-33% is enough
• Large RAM systems: avoid uncapped large zram sizes unless you measured a benefit
• Compression: zstd for good ratio, lz4 for lower CPU overhead
• Swap priority: keep zram priority higher than disk swap

Then monitor for a few days before tuning further.

Quick Tuning Checklist: 33% or 50%?

Run these before deciding on a size:

1. Check current tmpfs usage:

df -h --type=tmpfs

If the total used across all tmpfs mounts is more than 1-2 GiB, lean toward the lower value.

2. Check how much RAM is already consumed by page cache:

free -h

The buff/cache row tells you how much RAM is used for disk cache. If it is already eating a large fraction of your total RAM, a smaller zram size is safer.

3. Check actual swap pressure after a typical workday:

cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree|Shmem'

• Shmem includes tmpfs allocations — if it is large relative to total RAM, be conservative with zram size.
• If SwapFree is still almost equal to SwapTotal, zram is barely being used and sizing matters less.

4. After enabling zram, check real compression ratio under load:

zramctl

Look at DISKSIZE vs COMPR. A ratio below 2:1 means you are paying compression overhead for little gain. In that case, reducing zram size or switching to lz4 makes more sense than increasing it.

---

Monitoring and Quick Checks

Useful commands:

zramctl
swapon --show
vmstat 1
cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'

Look at:

• Whether zram is actually used under load
• Compression ratio (DATA vs COMPR in zramctl)
• Signs of heavy sustained memory pressure (constant swap churn)

---

Final Thoughts

zram is not a magic RAM upgrade, but it is still one of the most effective low-effort Linux memory optimizations when used in the right context.

For me, this really feels like a full-circle moment: from squeezing 128 MB Android phones years ago to making modern Linux systems more resilient and cost-efficient today.

If RAM is expensive, hardware upgrades are delayed, or you run many lightweight services, zram deserves another look.

---

Want to help fuel more posts? You know what to do: