Slackware -current ships with ZRAM swap enabled by default through /etc/default/zram and /etc/rc.d/rc.S. The default compression algorithm is zstd, but the kernel supports several alternatives, each with different trade-offs between compression ratio, CPU cost, and latency. This howto explains the available algorithms and helps you choose the most appropriate one for your workload.

ZRAM is a kernel feature that creates a compressed RAM-based block device. When used as swap, pages that would otherwise be written to disk are compressed and stored in RAM, providing faster swap I/O than a disk-backed swap partition or file. The trade-off is CPU time: compressing and decompressing pages costs CPU cycles.

A ZRAM device is configured with a fixed maximum uncompressed size (the disksize), but only consumes RAM proportional to the compressed size of pages actually swapped into it. An empty ZRAM device occupies almost no memory.

On Slackware -current, the configuration file looks like this:

# Should we use swap on ZRAM?
ZRAM_ENABLE=1

# Total system RAM, in KB:
MEMTOTAL=$(echo $(cat /proc/meminfo | grep ^MemTotal:) | cut -f 2 -d ' ')

# ZRAM device size.
ZRAMSIZE=$MEMTOTAL

# Number of ZRAM devices.
ZRAMNUMBER=1

# Set the compression algorithm.
ZRAMCOMPRESSION=zstd

# Set the swap priority for the ZRAM device:
ZRAMPRIORITY=100

The ZRAMCOMPRESSION value can be changed to any algorithm supported by your kernel.

To see the list of compression algorithms supported by your running kernel:

$ cat /sys/block/zram0/comp_algorithm
lzo lzo-rle lz4 lz4hc 842 [zstd]

The algorithm currently in use is shown in square brackets. The exact list depends on which compression modules your kernel has compiled in or available. Common algorithms are described below.

A very fast compression algorithm prioritizing speed over compression ratio. Compression and decompression are extremely lightweight, with minimal CPU overhead and very low latency.

• Compression ratio: roughly 1.5:1 to 2:1 on typical data
• CPU cost: very low
• Latency: very low
• Use case: systems with abundant RAM where ZRAM is used as a fast buffer for occasional memory spikes; latency-sensitive workloads; battery-powered devices where CPU overhead translates directly to power consumption

A higher-compression variant of lz4. Compression is significantly slower than plain lz4, but decompression remains fast. Useful when data is written once and read many times.

• Compression ratio: roughly 2:1
• CPU cost: higher on compression, low on decompression
• Latency: moderate on writes, low on reads
• Use case: read-heavy workloads where compression cost is amortized over many reads

An older fast compression algorithm. Similar performance profile to lz4 but generally with slightly lower compression ratio and slightly higher CPU cost. Maintained mostly for compatibility.

• Compression ratio: roughly 2:1
• CPU cost: low
• Latency: low

A variant of lzo optimized for run-length encoding patterns commonly found in memory pages (long runs of zeros). Often outperforms plain lzo on real swap data.

• Compression ratio: roughly 2:1, sometimes better than lzo
• CPU cost: low
• Latency: low
• Use case: drop-in replacement for lzo with better real-world performance

A modern compression algorithm offering very high compression ratios at a moderate CPU cost. The default in Slackware -current and most modern distributions.

• Compression ratio: roughly 3:1, sometimes higher
• CPU cost: moderate (higher than lz4, lower than older heavyweight algorithms)
• Latency: moderate
• Use case: systems where memory is the primary constraint; maximizing the effective swap capacity matters more than minimizing latency; workloads with frequent but moderate swap activity

A specialized algorithm originally developed for IBM POWER hardware-accelerated compression. Without hardware acceleration, software performance is generally inferior to other options. Rarely useful outside POWER systems.

The optimal choice depends on the relationship between available RAM, expected swap usage, and how latency-sensitive the workload is.

On systems with limited memory, maximizing how much can be stored in ZRAM matters more than minimizing CPU cost. Higher compression ratios mean more pages fit into the same RAM budget, delaying the point at which the system runs out of memory or has to fall back to disk swap.

Recommended: zstd

On systems with abundant RAM, ZRAM is rarely heavily used. The device exists as a fast buffer for transient memory pressure rather than as a true memory extender. In this case, latency and CPU cost matter more than compression ratio.

Recommended: lz4 or lzo-rle

CPU activity on a laptop translates to heat, fan noise, and battery drain. Lighter compression algorithms reduce this overhead, especially when ZRAM is actively used.

Recommended: lz4

If swap is used to evict cold pages that are occasionally faulted back in (rather than continually written), compression cost is amortized over many reads.

Recommended: lz4hc or zstd

Choosing an appropriate ZRAMSIZE depends on the relationship between system RAM and expected memory pressure. The default of ZRAMSIZE=$MEMTOTAL is a generic value that works on any system but is rarely optimal.

Two principles guide sizing:

• ZRAM only consumes RAM proportional to the compressed pages actually stored. An empty 8 GB ZRAM device occupies almost no memory.
• If ZRAM fills, the compressed pages occupy real RAM, reducing what is available for active processes. A ZRAM device sized close to total RAM can theoretically consume the system's working memory entirely under heavy pressure.

ZRAM functions as a memory extender. Maximizing the size matters because the alternative is hitting OOM or falling back to slow disk swap.

Recommended: 25% to 50% of RAM. For example, on a 4 GB system, ZRAMSIZE=2097152 (2 GB).

ZRAM still provides meaningful breathing room. Workloads with browsers, virtual machines, or compilations may push the system to swap occasionally.

Recommended: 25% of RAM, typically 4 GB. For example, on a 16 GB system, ZRAMSIZE=4194304 (4 GB).

ZRAM is rarely heavily used. The device serves as a fast buffer for transient memory spikes. A fixed 4 to 8 GB device is sufficient regardless of total RAM.

Recommended: 4 GB to 8 GB fixed, independent of total RAM. For example, on a 32 GB or 40 GB system, ZRAMSIZE=8388608 (8 GB) provides ample buffer without dedicating excessive address space to a feature that will rarely be used.

On systems with very little RAM (such as Raspberry Pi or older laptops with 1 to 2 GB), ZRAM can substantially extend usable memory. Higher proportions are common on these devices.

Recommended: 50% of RAM with zstd for maximum effective capacity.

ZRAMSIZE is in kilobytes. To convert from gigabytes:

1 GB = 1048576 KB
2 GB = 2097152 KB
4 GB = 4194304 KB
8 GB = 8388608 KB
16 GB = 16777216 KB

To set the value dynamically based on a fraction of total RAM, the existing MEMTOTAL variable in the configuration file can be used:

# 25% of total RAM
ZRAMSIZE=$((MEMTOTAL / 4))

# 50% of total RAM
ZRAMSIZE=$((MEMTOTAL / 2))

This approach scales automatically if RAM is added or removed from the system.

To change the algorithm permanently, edit /etc/default/zram and modify the ZRAMCOMPRESSION line:

ZRAMCOMPRESSION=lz4

Reboot to apply, or apply at runtime by reinitialising the ZRAM device (commands run as root):

# swapoff /dev/zram0
# zramctl --reset /dev/zram0
# zramctl --find --algorithm lz4 --size 8G
# mkswap /dev/zram0
# swapon --priority 100 /dev/zram0

Verify the new algorithm is active:

$ zramctl
NAME       ALGORITHM DISKSIZE  DATA  COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4             8G    0B    0B    0B       8 [SWAP]

The default ZRAMSIZE=$MEMTOTAL creates a ZRAM device equal to total system RAM. This is a generic default that works on systems of any size but is not optimal for high-memory systems. The kernel documentation specifically warns:

There is little point creating a zram of greater than twice the size of memory
since we expect a 2:1 compression ratio.

For systems with abundant RAM where ZRAM serves as an occasional buffer, a smaller disksize (4 GB or 8 GB) is generally more appropriate than a full RAM-sized device.

To benchmark a specific algorithm against your workload, monitor ZRAM statistics during heavy use:

$ cat /sys/block/zram0/mm_stat

Key fields are orig_data_size (uncompressed bytes stored), compr_data_size (compressed bytes stored), and mem_used_total (total RAM consumed including overhead). The ratio of orig_data_size to compr_data_size is the effective compression ratio for your data.

On a properly sized system under typical workload, swap usage should remain at zero during normal operation:

$ swapon --show
NAME           TYPE      SIZE USED PRIO
/dev/nvme0n1p2 partition 3.7G   0B   -1
/dev/zram0     partition   8G   0B  100

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            38Gi       2.6Gi        35Gi       399Mi       1.4Gi        36Gi
Swap:           11Gi          0B        11Gi

The USED column showing 0B for both swap devices indicates that ZRAM is configured but never actually needed under the current workload — the desired state for a system with sufficient RAM.

• The kernel ZRAM documentation: https://docs.kernel.org/admin-guide/blockdev/zram.html
• zramctl(8) man page
• /etc/default/zram configuration file
• /etc/rc.d/rc.S — where ZRAM is initialised at boot

* Originally written by r1w1s1