Memory Compression - Learning Module

Loading content...

0/227

Performance Tradeoffs

Nothing Is Free: The Art of Tradeoffs

Memory compression is not magic—it's an engineering tradeoff. Every byte saved in RAM costs CPU cycles to compress and decompress. Every page kept in compressed cache avoids disk I/O but adds latency to access.

The central question is: When does this tradeoff favor compression?

The answer depends on a complex interplay of factors:

How much memory pressure exists?
How fast is the CPU relative to memory/disk?
How compressible is the workload's data?
What latency is acceptable?
How is the system balanced overall?

Understanding these tradeoffs separates engineers who blindly enable compression from those who deploy it strategically for measurable benefit.

What You Will Learn

By the end of this page, you will deeply understand when memory compression helps versus hurts, the key performance metrics to monitor, systematic approaches to optimization, and real-world deployment strategies for different system profiles.

The Fundamental Tradeoff: CPU vs Memory vs I/O

Memory compression sits at the intersection of three scarce resources: CPU, memory, and I/O. Understanding how it affects each is essential.

Without Compression:

Page Out: Memory → Disk I/O (slow, ~10 μs SSD, ~10 ms HDD)
Page In:  Disk I/O → Memory (same latency)
CPU: Not involved in data transformation

With Compression:

Page Out: Memory → CPU (compress) → Compressed Memory (~1 μs)
Page In:  Compressed Memory → CPU (decompress) → Memory (~0.3 μs)
Disk I/O: Only when compression pool overflows

The tradeoff equation:

Benefit = (Avoided I/O Latency) - (Compression Overhead)

Where:
- Avoided I/O Latency = (Page faults that hit compression cache) × (Disk latency)
- Compression Overhead = (Compress time) + (Decompress time) + (Cache management)

Converting Mermaid diagram...

When Compression Wins:

Scenario	Why Compression Helps
High memory pressure, slow disk	Avoid expensive disk I/O
Good data compressibility	High effective memory gain
CPU has idle cycles	Compression doesn't compete with work
Interactive workloads	Lower latency than swap
Virtualized environments	Memory overcommit enabled

When Compression Loses:

Scenario	Why Compression Hurts
CPU-bound workloads	Compression steals cycles from work
Incompressible data	CPU spent, no memory saved
No memory pressure	Overhead with no benefit
Very fast storage	NVMe approaches compression latency
Real-time requirements	Unpredictable latency spikes

The 'Free Lunch' Myth

Memory compression is sometimes marketed as 'free memory.' It's not free—you pay in CPU cycles. However, for many workloads, CPU is abundant while memory or I/O bandwidth is scarce. In those cases, trading cheap CPU for expensive memory/I/O is an excellent bargain.

Latency Analysis: Where the Time Goes

Understanding latency components helps identify optimization opportunities. Let's break down the time spent in each operation:

Compression Path (Page Out):

Step	LZ4	Zstd	Description
Page selection	10 ns	10 ns	Evaluate compression candidacy
kmap/kunmap	20 ns	20 ns	Map page for access
Same-check	50 ns	50 ns	Check for zero/same-filled
Compression	800 ns	3000 ns	Actual compression
Pool allocation	100 ns	100 ns	Allocate compressed storage
Memory copy	100 ns	100 ns	Copy to pool
Metadata update	50 ns	50 ns	Index, LRU update
Total	~1.1 μs	~3.3 μs	End-to-end

Decompression Path (Page Fault):

Step	LZ4	Zstd	Description
Fault handling	100 ns	100 ns	MMU trap, handler dispatch
Index lookup	50 ns	50 ns	Find compressed entry
Page allocation	100 ns	100 ns	Get free frame
Pool mapping	30 ns	30 ns	Map compressed data
Decompression	200 ns	350 ns	Actual decompression
Page table update	100 ns	100 ns	Update mappings
TLB invalidation	100 ns	100 ns	Notify other CPUs
Total	~680 ns	~830 ns	End-to-end

Compare to Swap Latency:

Storage Type	Latency	vs LZ4 Decompress
LZ4 decompress	680 ns	1x (baseline)
Zstd decompress	830 ns	1.2x
NVMe SSD	10 μs	15x slower
SATA SSD	100 μs	150x slower
HDD	10 ms	15,000x slower

Latency Distribution Matters

Average latency doesn't tell the whole story. Compression latency is consistent (~1 μs ± 0.5 μs). Disk latency varies wildly (10 μs to 100 ms depending on queue depth, seek time, write amplification). For interactive workloads, consistent low latency is more valuable than occasionally-fast average latency.

latency_measurement.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/bin/bash
# Measure actual compression latency on your system
 
# Using perf to measure zswap operations
sudo perf probe --add 'zswap_frontswap_store'
sudo perf probe --add 'zswap_frontswap_store%return'
 
echo "Running perf record for 10 seconds..."
sudo perf record -e probe:zswap_frontswap_store                  -e probe:zswap_frontswap_store__return                  -a sleep 10
 
echo "Analyzing latency distribution..."
sudo perf script | awk '
    /zswap_frontswap_store[^_]/ {start[$4] = $1}
    /zswap_frontswap_store__return/ {
        if ($4 in start) {
            latency = $1 - start[$4]
            if (latency > 0) print latency * 1000000 "us"
            delete start[$4]
        }
    }
' | sort -n | awk '
    {a[NR]=$1; sum+=$1}
    END {
        print "Samples:  " NR
        print "Average:  " sum/NR
        print "Median:   " a[int(NR/2)]
        print "P95:      " a[int(NR*0.95)]
        print "P99:      " a[int(NR*0.99)]
    }
'
 
# Cleanup probes
sudo perf probe --del 'zswap_frontswap_store*'

CPU Overhead Analysis

Memory compression consumes CPU cycles. Understanding this overhead helps determine when compression is appropriate.

CPU Cost Components:

Compression kernel time — Direct CPU spent on compression algorithms
Cache pollution — Working data evicted from CPU caches
Context switching — If compression happens in kernel threads
Lock contention — Synchronization overhead on multi-core
Memory bandwidth — Reading input, writing compressed output

Estimating CPU Impact:

For a workload generating R page-outs per second and F page faults per second hitting the compression cache:

CPU Overhead = (R × Compression_Time) + (F × Decompression_Time)

Example with LZ4:
- 1000 page-outs/sec × 1 μs = 1 ms CPU time per second
- 5000 page faults/sec × 0.3 μs = 1.5 ms CPU time per second
- Total: 2.5 ms per second = 0.25% of one CPU core

Example with Zstd:
- 1000 page-outs/sec × 3 μs = 3 ms CPU time per second
- 5000 page faults/sec × 0.4 μs = 2 ms CPU time per second
- Total: 5 ms per second = 0.5% of one CPU core

CPU Overhead Scenarios
Scenario	Page-outs/s	Faults/s	LZ4 CPU%	Zstd CPU%
Light pressure	100	500	0.03%	0.05%
Moderate pressure	1,000	5,000	0.25%	0.5%
Heavy pressure	10,000	50,000	2.5%	5%
Thrashing	100,000	500,000	25%	50%

Key Insight: Even under heavy memory pressure, compression CPU overhead is typically modest (2-5% of a core). The exception is thrashing—if the system is constantly compressing and decompressing due to insufficient memory, overhead skyrockets.

Monitoring CPU Usage:

cpu_overhead_monitoring.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#!/bin/bash
# Monitor compression-related CPU usage
 
echo "=== Compression CPU Overhead Analysis ==="
 
# Method 1: Check kernel CPU time in compression code
# Requires function tracing or perf
 
# Method 2: Compare overall CPU before/after enabling compression
echo ""
echo "Current CPU by kernel function (top 10 compression-related):"
sudo perf top -e cpu-clock --no-children 2>/dev/null |     head -30 | grep -E 'lz4|lzo|zstd|zswap|zram|zpool|zs_' ||     echo "  (Run 'sudo perf top' manually to see)"
 
# Method 3: Monitor softirq and system time
echo ""
echo "System CPU breakdown (look for increased sys%):"
mpstat 1 5
 
# Method 4: cgroup-based monitoring (if containerized)
if [ -d "/sys/fs/cgroup/cpu" ]; then
    echo ""
    echo "Cgroup CPU stats available at /sys/fs/cgroup/cpu/"
fi
 
# Estimate from stats
echo ""
echo "=== Rough Estimate from zswap Stats ==="
if [ -d "/sys/kernel/debug/zswap" ]; then
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    loaded=$(cat /sys/kernel/debug/zswap/loaded_pages 2>/dev/null || echo 0)
    
    # Rough estimate: 1 μs per page with LZ4
    compress_time_us=$stored
    decompress_time_us=$((loaded / 3))  # Decompression faster
    
    echo "Estimated total compression time: ${compress_time_us} μs"
    echo "Estimated total decompression time: ${decompress_time_us} μs"
fi

CPU-Bound Workloads

For CPU-bound workloads (video encoding, scientific computing), even 0.5% CPU overhead represents stolen work. Consider disabling compression or using the fastest algorithm (LZ4). For I/O-bound or memory-bound workloads, trading 5% CPU for 50% less swap I/O is usually worthwhile.

Memory Efficiency Analysis

The goal of memory compression is to increase effective memory capacity. But the actual gain depends on several factors:

Effective Memory Gain:

Effective_Memory = Physical_RAM + (Compressed_Pages × (Ratio - 1) / Ratio)

Example:
- Physical RAM: 8 GB
- Compressed pages: 2 GB logical (stored in 0.8 GB physical)
- Ratio: 2.5:1

Effective_Memory = 8 + (2 × 1.5/2.5) = 8 + 1.2 = 9.2 GB

'Free' memory gained: 1.2 GB (but at CPU cost)

Memory Overhead Components:

Compression pool — Fixed allocation for compressed data storage
Metadata — Per-page tracking structures (~40-80 bytes per compressed page)
Allocator overhead — zsmalloc/zbud internal fragmentation
Working buffers — Per-CPU compression contexts

Net Memory Calculation:

Net_Gain = (Original_Size - Compressed_Size) - Overhead

Where:
- Original_Size = Pages_Compressed × PAGE_SIZE
- Compressed_Size = Actual pool usage
- Overhead = Metadata + Fragmentation

memory_efficiency_calc.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
#!/bin/bash
# Calculate actual memory efficiency
 
echo "=== Memory Compression Efficiency Analysis ==="
 
# zswap analysis
if [ -d "/sys/kernel/debug/zswap" ]; then
    echo ""
    echo "zswap Efficiency:"
    
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    pool_size=$(cat /sys/kernel/debug/zswap/pool_total_size 2>/dev/null || echo 0)
    same=$(cat /sys/kernel/debug/zswap/same_filled_pages 2>/dev/null || echo 0)
    
    if [ "$stored" -gt 0 ] && [ "$pool_size" -gt 0 ]; then
        original=$((stored * 4096))
        
        ratio=$(echo "scale=2; $original / $pool_size" | bc)
        savings=$((original - pool_size))
        
        echo "  Original data size:  $(numfmt --to=iec $original)"
        echo "  Pool memory used:    $(numfmt --to=iec $pool_size)"
        echo "  Same-filled pages:   $same (essentially free)"
        echo "  Compression ratio:   ${ratio}:1"
        echo "  Memory saved:        $(numfmt --to=iec $savings)"
        echo "  Efficiency:          $((savings * 100 / original))%"
    else
        echo "  No data stored yet"
    fi
fi
 
# zram analysis
for zram in /sys/block/zram*; do
    if [ -d "$zram" ] && [ -f "$zram/mm_stat" ]; then
        device=$(basename $zram)
        echo ""
        echo "$device Efficiency:"
        
        read -r orig compr used limit max same compact huge <<< $(cat $zram/mm_stat)
        
        if [ "$orig" -gt 0 ]; then
            ratio=$(echo "scale=2; $orig / $compr" | bc)
            overhead=$((used - compr))
            net_savings=$((orig - used))
            
            echo "  Original data:       $(numfmt --to=iec $orig)"
            echo "  Compressed data:     $(numfmt --to=iec $compr)"
            echo "  Total memory used:   $(numfmt --to=iec $used)"
            echo "  Compression ratio:   ${ratio}:1"
            echo "  Allocator overhead:  $(numfmt --to=iec $overhead)"
            echo "  Net memory saved:    $(numfmt --to=iec $net_savings)"
            echo "  Same-filled pages:   $same"
            echo "  Huge (incompress):   $huge"
            
            if [ "$huge" -gt 0 ] && [ "$same" -gt 0 ]; then
                total_special=$((same + huge))
                pct=$((total_special * 100 / (orig / 4096)))
                echo "  Special handling:    $pct% of pages"
            fi
        fi
    fi
done

Workload-Specific Ratios

Compression ratio varies dramatically by workload. Desktop/browser: 2-3:1. Server with text processing: 3-4:1. Scientific computing: 1.5-2:1. Encrypted workloads: 1.0-1.1:1. Measure YOUR workload before capacity planning.

Workload Classification and Strategy

Different workloads require different compression strategies. Here's a classification framework:

Workload Dimensions:

Memory Pressure: None / Low / Moderate / High / Critical
CPU Utilization: Idle / Low / Moderate / High / Saturated
Data Compressibility: Poor / Fair / Good / Excellent
Latency Sensitivity: Batch / Interactive / Real-time
I/O Pattern: Sequential / Random / Mixed

Workload Profiles and Recommendations
Profile	Characteristics	Recommendation
Desktop/Browser	Moderate memory, low CPU, good compressibility, interactive	Enable zswap or zram, LZ4, moderate pool
Database Server	High memory, moderate CPU, fair compressibility, latency-sensitive	Cautious: test thoroughly, consider LZ4 only
Build Server	Variable pressure, high CPU peaks, good compressibility, batch	Disable during builds, enable at idle
Container Host	Overcommit needed, moderate CPU, variable compressibility	zram per container or host zswap
ML Training	High memory, saturated CPU, poor compressibility (floats)	Likely disable; CPU too precious
Java Application	High heap, GC pauses, good compressibility	Enable cautiously; monitor GC impact
File Server	Cache-heavy, low CPU, filesystem already compressed	Minimal benefit; skip compression
Embedded System	Fixed memory, low CPU, variable data	zram with small pool; saves flash writes

Decision Framework:

Converting Mermaid diagram...

Adaptive Approaches

Some systems benefit from dynamic adjustment: compress aggressively at night during batch jobs, minimize during day for interactive response. While not built into zswap/zram, external scripts can adjust parameters based on time or detected workload patterns.

Benchmarking Methodology

Effective benchmarking requires measuring the right metrics under realistic conditions. Here's a systematic approach:

Key Metrics to Measure:

Application performance — Throughput, latency, response time
Memory efficiency — Working set size, compression ratio, pool usage
CPU overhead — Compression-related CPU time
I/O reduction — Swap read/write IOPS, bandwidth
Tail latency — P95, P99 response times

Benchmarking Protocol:

Benchmarking Steps

•Establish baseline — Run workload WITHOUT compression, record all metrics
•Enable compression — Configure zswap or zram with default settings
•Run identical workload — Same duration, same input, same conditions
•Record all metrics — Application AND system metrics
•Vary configuration — Test different algorithms, pool sizes
•Analyze tradeoffs — Compare application performance vs overhead
•Stress test — Push memory to 90%+, observe behavior under pressure
•Validate conclusions — Multiple runs, statistical significance

compression_benchmark.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
#!/bin/bash
# Comprehensive compression benchmarking script
 
WORKLOAD="$1"  # Command to run as workload
DURATION="${2:- 60
                        }"  # Seconds to run
OUTPUT_DIR = "${3:-./benchmark_results}"
 
mkdir - p "$OUTPUT_DIR"
 
run_benchmark() {
                            local name="$1"
    local config="$2"
    
    echo "=== Running benchmark: $name ==="
    
    # Apply configuration
    eval "$config"
    
    # Clear caches
    sync && echo 3 > /proc/sys / vm / drop_caches
    
    # Start monitoring
    vmstat 1 > "$OUTPUT_DIR/${name}_vmstat.log" &
                        VMSTAT_PID=$!
    
    sar - r 1 > "$OUTPUT_DIR/${name}_memory.log" 2 >& 1 &
                        SAR_PID=$!
    
    # Record start stats
    cat / sys / kernel / debug / zswap/* > "$OUTPUT_DIR/${name}_zswap_start.txt" 2>/dev/null
    cat /sys/block/zram0/mm_stat > "$OUTPUT_DIR/${name}_zram_start.txt" 2>/dev/null
    
    # Run workload with timing
    START_TIME=$(date +%s.%N)
    eval "$WORKLOAD" > "$OUTPUT_DIR/${name}_workload.log" 2>&1
    END_TIME=$(date +%s.%N)
    
    # Record end stats
    cat /sys/kernel/debug/zswap/* > "$OUTPUT_DIR/${name}_zswap_end.txt" 2>/dev/null
    cat /sys/block/zram0/mm_stat > "$OUTPUT_DIR/${name}_zram_end.txt" 2>/dev/null
    
    # Stop monitoring
    kill $VMSTAT_PID $SAR_PID 2>/dev/null
    
    # Calculate metrics
    ELAPSED=$(echo "$END_TIME - $START_TIME" | bc)
    echo "  Elapsed time: ${ELAPSED}s"
    
    # Parse swap I/O from vmstat
    SWAP_IN=$(awk 'NR>2 {sum+=$7} END {print sum}' "$OUTPUT_DIR/${name}_vmstat.log")
    SWAP_OUT=$(awk 'NR>2 {sum+=$8} END {print sum}' "$OUTPUT_DIR/${name}_vmstat.log")
    echo "  Swap in pages: $SWAP_IN"
    echo "  Swap out pages: $SWAP_OUT"
    
    # Record summary
    cat >> "$OUTPUT_DIR/summary.csv" <<EOF
$name,$ELAPSED,$SWAP_IN,$SWAP_OUT
EOF
}
 
# Initialize summary
echo "config,elapsed_time,swap_in,swap_out" > "$OUTPUT_DIR/summary.csv"
 
# Baseline: no compression
run_benchmark "no_compression" "
    swapoff /dev/zram0 2>/dev/null
    echo N > /sys/module/zswap/parameters/enabled
    swapon /dev/sda2  # Regular swap
"
 
# zswap with LZ4
run_benchmark "zswap_lz4" "
    swapoff /dev/zram0 2>/dev/null
    echo Y > /sys/module/zswap/parameters/enabled
    echo lz4 > /sys/module/zswap/parameters/compressor
    echo 25 > /sys/module/zswap/parameters/max_pool_percent
    swapon /dev/sda2
"
 
# zswap with Zstd
run_benchmark "zswap_zstd" "
    echo zstd > /sys/module/zswap/parameters/compressor
"
 
# zram with LZ4
run_benchmark "zram_lz4" "
    echo N > /sys/module/zswap/parameters/enabled
    swapoff -a
    modprobe zram
    echo 1 > /sys/block/zram0/reset
    echo lz4 > /sys/block/zram0/comp_algorithm
    echo 4G > /sys/block/zram0/disksize
    mkswap /dev/zram0
    swapon -p 100 /dev/zram0
"
 
echo ""
echo "=== Benchmark Complete ==="
echo "Results in: $OUTPUT_DIR"
cat "$OUTPUT_DIR/summary.csv"

Reproducibility

Memory benchmarks are notoriously hard to reproduce. Control for: page cache state (drop caches between runs), background processes, NUMA effects, thermal throttling, and timing jitter. Run multiple iterations and report confidence intervals, not just averages.

Tuning Strategies

Based on benchmarking results, apply targeted tuning to optimize for your specific workload:

Algorithm Tuning:

Goal	Action	Rationale
Minimize latency	Use LZ4	Fastest decompression
Maximize ratio	Use Zstd level 3	Best compression
Balance	Use LZO-RLE or Zstd-1	Moderate speed and ratio
Handle encrypted	Enable same-filled only	Skip compression, catch zeros

Pool Size Tuning:

Too small: High eviction rate → increased I/O → defeats purpose
Too large: Steals from application memory → may worsen pressure
Starting point: 20-25% of RAM
Adjust based on: Hit rate (higher = pool is working), eviction rate (lower = pool is sufficient)

Workload-Specific Tuning:

Latency-Sensitive Tuning

•Use LZ4 only
•Smaller pool (15-20%)
•Aggressive same-filled detection
•Consider priority-based compression
•Monitor P99 latency continuously

Memory-Critical Tuning

•Use Zstd for better ratio
•Larger pool (40-50%)
•Enable writeback if needed
•Tune zpool allocator (zsmalloc)
•Monitor compression ratio trends

tuning_recommendations.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#!/bin/bash
# Generate tuning recommendations based on metrics
 
echo "=== Compression Tuning Advisor ==="
echo ""
 
# Collect current metrics
if [ -d "/sys/kernel/debug/zswap" ]; then
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    pool_size=$(cat /sys/kernel/debug/zswap/pool_total_size 2>/dev/null || echo 0)
    reject_poor=$(cat /sys/kernel/debug/zswap/reject_compress_poor 2>/dev/null || echo 0)
    pool_limit=$(cat /sys/kernel/debug/zswap/pool_limit_hit 2>/dev/null || echo 0)
    written_back=$(cat /sys/kernel/debug/zswap/written_back_pages 2>/dev/null || echo 0)
    
    mem_total_kb=$(awk '/MemTotal/ {print $2}' /proc/meminfo)
    pool_pct=$((pool_size * 100 / (mem_total_kb * 1024)))
    
    echo "Current State:"
    echo "  Pool usage: ${pool_pct}% of RAM"
    echo "  Stored pages: $stored"
    echo "  Rejected (poor compression): $reject_poor"
    echo "  Pool limit hits: $pool_limit"
    echo "  Written back: $written_back"
    echo ""
    
    # Generate recommendations
    echo "Recommendations:"
    
    # Check rejection rate
    if [ "$stored" -gt 0 ]; then
        reject_rate=$((reject_poor * 100 / (stored + reject_poor)))
        if [ "$reject_rate" -gt 30 ]; then
            echo "  ⚠ High rejection rate (${reject_rate}%)"
            echo "    → Workload may have incompressible data"
            echo "    → Consider: LZ4 (faster bypass) or disable compression"
        fi
    fi
    
    # Check pool limit hits
    if [ "$pool_limit" -gt 0 ]; then
        echo "  ⚠ Pool limit was hit $pool_limit times"
        echo "    → Consider: Increase max_pool_percent"
        echo "    → Or: Enable writeback to backing device"
    fi
    
    # Check writeback activity
    if [ "$written_back" -gt 0 ] && [ "$stored" -gt 0 ]; then
        wb_rate=$((written_back * 100 / stored))
        if [ "$wb_rate" -gt 20 ]; then
            echo "  ⚠ High writeback rate (${wb_rate}%)"
            echo "    → Pool may be too small"
            echo "    → Consider: Increase pool size"
        fi
    fi
    
    # Pool size recommendations
    if [ "$pool_pct" -lt 15 ]; then
        echo "  💡 Pool is small (${pool_pct}%)"
        echo "    → May not be capturing full benefit"
        echo "    → Consider: Increase to 20-30%"
    elif [ "$pool_pct" -gt 50 ]; then
        echo "  💡 Pool is large (${pool_pct}%)"
        echo "    → May be starving applications"
        echo "    → Monitor application memory allocation failures"
    fi
    
    # Calculate compression ratio
    if [ "$pool_size" -gt 0 ] && [ "$stored" -gt 0 ]; then
        orig=$((stored * 4096))
        ratio=$(echo "scale=2; $orig / $pool_size" | bc)
        
        echo ""
        echo "Compression ratio: ${ratio}:1"
        
        if [ "$(echo "$ratio < 1.5" | bc)" -eq 1 ]; then
            echo "  ⚠ Low compression ratio"
            echo "    → Benefits may not justify overhead"
            echo "    → Consider: Disabling compression for this workload"
        elif [ "$(echo "$ratio > 3.0" | bc)" -eq 1 ]; then
            echo "  ✓ Excellent compression ratio"
            echo "    → Compression is very effective"
            echo "    → Consider: Larger pool to cache more"
        fi
    fi
    
else
    echo "zswap not enabled or debugfs not mounted"
fi
 
echo ""
echo "Run this script periodically during typical workload for best results."

Real-World Case Studies

Understanding how memory compression performs in real deployments provides practical insight. Here are documented case studies:

Case Study 1: Desktop Linux with Firefox/Chrome

Profile: 8GB RAM, heavy browser use (50+ tabs), moderate CPU usage

Metric	Without Compression	With zram (LZ4)
Tab switches	200-2000 ms	50-200 ms
System swap usage	2-4 GB	< 100 MB
Tab discards	Frequent	Rare
CPU overhead	-	0.5-1%

Conclusion: Dramatic improvement in responsiveness. Browser tab data compresses well (3:1+). LZ4 recommended for consistent low latency.

Case Study 2: Container Host with Memory Overcommit

Profile: 64GB host, 100 containers with 1GB limit each (100GB logical), variable workloads

Metric	Without Compression	With zswap (Zstd)
SSD swap I/O	50-200 MB/s	5-20 MB/s
Container OOM kills	5-10/day	1-2/day
P99 response time	500 ms	150 ms
CPU overhead	-	2-3%

Conclusion: 80% reduction in swap I/O enables higher container density. Zstd's better ratio justifies CPU cost in this scenario.

Case Study 3: Database Server (PostgreSQL)

Profile: 256GB RAM, PostgreSQL with 200GB shared buffers, complex queries

Metric	Without Compression	With zswap (LZ4)
Query latency P50	12 ms	13 ms (+8%)
Query latency P99	150 ms	180 ms (+20%)
Memory headroom	20 GB	45 GB
Emergency OOM events	Monthly	None

Conclusion: Database sees slight latency regression due to compression overhead on hot data. However, additional memory headroom prevents OOM during query spikes. Acceptable tradeoff for improved stability.

Case Study 4: ML Training (Encrypted Data)

Profile: GPU training with encrypted datasets

Metric	Without Compression	With zram
Training throughput	Baseline	-2%
GPU utilization	95%	93%
Compression ratio	-	1.05:1
CPU overhead	-	3%

Conclusion: Encrypted data doesn't compress. CPU overhead provides no benefit and slightly reduces GPU feed rate. Compression disabled for this workload.

Learn from Others, Validate for Yourself

These case studies provide guidance, but every deployment is unique. Use them to form hypotheses about YOUR workload, then validate with controlled benchmarks. A 10-minute benchmark can save hours of production troubleshooting.

Summary: Performance Tradeoffs

We've comprehensively explored the performance tradeoffs inherent in memory compression. Let's consolidate the essential understanding:

Key Takeaways

•Compression trades CPU for memory/I/O — This tradeoff is favorable when CPU is cheaper than what you're avoiding.
•Latency analysis reveals optimization opportunities — Know where time goes to know where to optimize.
•CPU overhead is usually modest — Typically 0.5-5% even under pressure; thrashing is the exception.
•Memory efficiency depends on workload — Measure actual compression ratio, not theoretical maximum.
•Classify your workload first — Different profiles require different strategies.
•Benchmark systematically — Control variables, measure the right metrics, validate conclusions.
•Tune iteratively — Start with defaults, adjust based on observed behavior.
•Real-world experience guides — Learn from case studies, but validate for your specific situation.

Final Recommendation:

For most systems under memory pressure, enabling memory compression (zswap with LZ4 or LZO-RLE) provides significant benefit with minimal downside. Start with defaults, monitor the metrics we've discussed, and tune as needed. The exception is CPU-bound workloads with incompressible data—there, compression adds overhead without benefit.

Remember: compression is a tool, not a magic solution. Applied thoughtfully based on workload analysis, it can dramatically improve system behavior. Applied blindly, it adds overhead. The knowledge you've gained enables thoughtful application.

Module Complete

Congratulations! You've completed the Memory Compression module. You now understand compressed page caches, zswap, zram, compression algorithms, and the performance tradeoffs governing their effective deployment. This knowledge equips you to optimize memory management in production systems across diverse workloads.

Performance Tradeoffs

Nothing Is Free: The Art of Tradeoffs

The central question is: When does this tradeoff favor compression?

The answer depends on a complex interplay of factors:

How much memory pressure exists?
How fast is the CPU relative to memory/disk?
How compressible is the workload's data?
What latency is acceptable?
How is the system balanced overall?

Understanding these tradeoffs separates engineers who blindly enable compression from those who deploy it strategically for measurable benefit.

What You Will Learn

The Fundamental Tradeoff: CPU vs Memory vs I/O

Memory compression sits at the intersection of three scarce resources: CPU, memory, and I/O. Understanding how it affects each is essential.

Without Compression:

Page Out: Memory → Disk I/O (slow, ~10 μs SSD, ~10 ms HDD)
Page In:  Disk I/O → Memory (same latency)
CPU: Not involved in data transformation

With Compression:

Page Out: Memory → CPU (compress) → Compressed Memory (~1 μs)
Page In:  Compressed Memory → CPU (decompress) → Memory (~0.3 μs)
Disk I/O: Only when compression pool overflows

The tradeoff equation:

Benefit = (Avoided I/O Latency) - (Compression Overhead)

Where:
- Avoided I/O Latency = (Page faults that hit compression cache) × (Disk latency)
- Compression Overhead = (Compress time) + (Decompress time) + (Cache management)

Converting Mermaid diagram...

When Compression Wins:

Scenario	Why Compression Helps
High memory pressure, slow disk	Avoid expensive disk I/O
Good data compressibility	High effective memory gain
CPU has idle cycles	Compression doesn't compete with work
Interactive workloads	Lower latency than swap
Virtualized environments	Memory overcommit enabled

When Compression Loses:

Scenario	Why Compression Hurts
CPU-bound workloads	Compression steals cycles from work
Incompressible data	CPU spent, no memory saved
No memory pressure	Overhead with no benefit
Very fast storage	NVMe approaches compression latency
Real-time requirements	Unpredictable latency spikes

The 'Free Lunch' Myth

Latency Analysis: Where the Time Goes

Understanding latency components helps identify optimization opportunities. Let's break down the time spent in each operation:

Compression Path (Page Out):

Step	LZ4	Zstd	Description
Page selection	10 ns	10 ns	Evaluate compression candidacy
kmap/kunmap	20 ns	20 ns	Map page for access
Same-check	50 ns	50 ns	Check for zero/same-filled
Compression	800 ns	3000 ns	Actual compression
Pool allocation	100 ns	100 ns	Allocate compressed storage
Memory copy	100 ns	100 ns	Copy to pool
Metadata update	50 ns	50 ns	Index, LRU update
Total	~1.1 μs	~3.3 μs	End-to-end

Decompression Path (Page Fault):

Step	LZ4	Zstd	Description
Fault handling	100 ns	100 ns	MMU trap, handler dispatch
Index lookup	50 ns	50 ns	Find compressed entry
Page allocation	100 ns	100 ns	Get free frame
Pool mapping	30 ns	30 ns	Map compressed data
Decompression	200 ns	350 ns	Actual decompression
Page table update	100 ns	100 ns	Update mappings
TLB invalidation	100 ns	100 ns	Notify other CPUs
Total	~680 ns	~830 ns	End-to-end

Compare to Swap Latency:

Storage Type	Latency	vs LZ4 Decompress
LZ4 decompress	680 ns	1x (baseline)
Zstd decompress	830 ns	1.2x
NVMe SSD	10 μs	15x slower
SATA SSD	100 μs	150x slower
HDD	10 ms	15,000x slower

Latency Distribution Matters

latency_measurement.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/bin/bash
# Measure actual compression latency on your system
 
# Using perf to measure zswap operations
sudo perf probe --add 'zswap_frontswap_store'
sudo perf probe --add 'zswap_frontswap_store%return'
 
echo "Running perf record for 10 seconds..."
sudo perf record -e probe:zswap_frontswap_store                  -e probe:zswap_frontswap_store__return                  -a sleep 10
 
echo "Analyzing latency distribution..."
sudo perf script | awk '
    /zswap_frontswap_store[^_]/ {start[$4] = $1}
    /zswap_frontswap_store__return/ {
        if ($4 in start) {
            latency = $1 - start[$4]
            if (latency > 0) print latency * 1000000 "us"
            delete start[$4]
        }
    }
' | sort -n | awk '
    {a[NR]=$1; sum+=$1}
    END {
        print "Samples:  " NR
        print "Average:  " sum/NR
        print "Median:   " a[int(NR/2)]
        print "P95:      " a[int(NR*0.95)]
        print "P99:      " a[int(NR*0.99)]
    }
'
 
# Cleanup probes
sudo perf probe --del 'zswap_frontswap_store*'

CPU Overhead Analysis

Memory compression consumes CPU cycles. Understanding this overhead helps determine when compression is appropriate.

CPU Cost Components:

Compression kernel time — Direct CPU spent on compression algorithms
Cache pollution — Working data evicted from CPU caches
Context switching — If compression happens in kernel threads
Lock contention — Synchronization overhead on multi-core
Memory bandwidth — Reading input, writing compressed output

Estimating CPU Impact:

For a workload generating R page-outs per second and F page faults per second hitting the compression cache:

CPU Overhead = (R × Compression_Time) + (F × Decompression_Time)

Example with LZ4:
- 1000 page-outs/sec × 1 μs = 1 ms CPU time per second
- 5000 page faults/sec × 0.3 μs = 1.5 ms CPU time per second
- Total: 2.5 ms per second = 0.25% of one CPU core

Example with Zstd:
- 1000 page-outs/sec × 3 μs = 3 ms CPU time per second
- 5000 page faults/sec × 0.4 μs = 2 ms CPU time per second
- Total: 5 ms per second = 0.5% of one CPU core

CPU Overhead Scenarios
Scenario	Page-outs/s	Faults/s	LZ4 CPU%	Zstd CPU%
Light pressure	100	500	0.03%	0.05%
Moderate pressure	1,000	5,000	0.25%	0.5%
Heavy pressure	10,000	50,000	2.5%	5%
Thrashing	100,000	500,000	25%	50%

Monitoring CPU Usage:

cpu_overhead_monitoring.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#!/bin/bash
# Monitor compression-related CPU usage
 
echo "=== Compression CPU Overhead Analysis ==="
 
# Method 1: Check kernel CPU time in compression code
# Requires function tracing or perf
 
# Method 2: Compare overall CPU before/after enabling compression
echo ""
echo "Current CPU by kernel function (top 10 compression-related):"
sudo perf top -e cpu-clock --no-children 2>/dev/null |     head -30 | grep -E 'lz4|lzo|zstd|zswap|zram|zpool|zs_' ||     echo "  (Run 'sudo perf top' manually to see)"
 
# Method 3: Monitor softirq and system time
echo ""
echo "System CPU breakdown (look for increased sys%):"
mpstat 1 5
 
# Method 4: cgroup-based monitoring (if containerized)
if [ -d "/sys/fs/cgroup/cpu" ]; then
    echo ""
    echo "Cgroup CPU stats available at /sys/fs/cgroup/cpu/"
fi
 
# Estimate from stats
echo ""
echo "=== Rough Estimate from zswap Stats ==="
if [ -d "/sys/kernel/debug/zswap" ]; then
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    loaded=$(cat /sys/kernel/debug/zswap/loaded_pages 2>/dev/null || echo 0)
    
    # Rough estimate: 1 μs per page with LZ4
    compress_time_us=$stored
    decompress_time_us=$((loaded / 3))  # Decompression faster
    
    echo "Estimated total compression time: ${compress_time_us} μs"
    echo "Estimated total decompression time: ${decompress_time_us} μs"
fi

CPU-Bound Workloads

Memory Efficiency Analysis

The goal of memory compression is to increase effective memory capacity. But the actual gain depends on several factors:

Effective Memory Gain:

Effective_Memory = Physical_RAM + (Compressed_Pages × (Ratio - 1) / Ratio)

Example:
- Physical RAM: 8 GB
- Compressed pages: 2 GB logical (stored in 0.8 GB physical)
- Ratio: 2.5:1

Effective_Memory = 8 + (2 × 1.5/2.5) = 8 + 1.2 = 9.2 GB

'Free' memory gained: 1.2 GB (but at CPU cost)

Memory Overhead Components:

Compression pool — Fixed allocation for compressed data storage
Metadata — Per-page tracking structures (~40-80 bytes per compressed page)
Allocator overhead — zsmalloc/zbud internal fragmentation
Working buffers — Per-CPU compression contexts

Net Memory Calculation:

Net_Gain = (Original_Size - Compressed_Size) - Overhead

Where:
- Original_Size = Pages_Compressed × PAGE_SIZE
- Compressed_Size = Actual pool usage
- Overhead = Metadata + Fragmentation

memory_efficiency_calc.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
#!/bin/bash
# Calculate actual memory efficiency
 
echo "=== Memory Compression Efficiency Analysis ==="
 
# zswap analysis
if [ -d "/sys/kernel/debug/zswap" ]; then
    echo ""
    echo "zswap Efficiency:"
    
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    pool_size=$(cat /sys/kernel/debug/zswap/pool_total_size 2>/dev/null || echo 0)
    same=$(cat /sys/kernel/debug/zswap/same_filled_pages 2>/dev/null || echo 0)
    
    if [ "$stored" -gt 0 ] && [ "$pool_size" -gt 0 ]; then
        original=$((stored * 4096))
        
        ratio=$(echo "scale=2; $original / $pool_size" | bc)
        savings=$((original - pool_size))
        
        echo "  Original data size:  $(numfmt --to=iec $original)"
        echo "  Pool memory used:    $(numfmt --to=iec $pool_size)"
        echo "  Same-filled pages:   $same (essentially free)"
        echo "  Compression ratio:   ${ratio}:1"
        echo "  Memory saved:        $(numfmt --to=iec $savings)"
        echo "  Efficiency:          $((savings * 100 / original))%"
    else
        echo "  No data stored yet"
    fi
fi
 
# zram analysis
for zram in /sys/block/zram*; do
    if [ -d "$zram" ] && [ -f "$zram/mm_stat" ]; then
        device=$(basename $zram)
        echo ""
        echo "$device Efficiency:"
        
        read -r orig compr used limit max same compact huge <<< $(cat $zram/mm_stat)
        
        if [ "$orig" -gt 0 ]; then
            ratio=$(echo "scale=2; $orig / $compr" | bc)
            overhead=$((used - compr))
            net_savings=$((orig - used))
            
            echo "  Original data:       $(numfmt --to=iec $orig)"
            echo "  Compressed data:     $(numfmt --to=iec $compr)"
            echo "  Total memory used:   $(numfmt --to=iec $used)"
            echo "  Compression ratio:   ${ratio}:1"
            echo "  Allocator overhead:  $(numfmt --to=iec $overhead)"
            echo "  Net memory saved:    $(numfmt --to=iec $net_savings)"
            echo "  Same-filled pages:   $same"
            echo "  Huge (incompress):   $huge"
            
            if [ "$huge" -gt 0 ] && [ "$same" -gt 0 ]; then
                total_special=$((same + huge))
                pct=$((total_special * 100 / (orig / 4096)))
                echo "  Special handling:    $pct% of pages"
            fi
        fi
    fi
done

Workload-Specific Ratios

Workload Classification and Strategy

Different workloads require different compression strategies. Here's a classification framework:

Workload Dimensions:

Memory Pressure: None / Low / Moderate / High / Critical
CPU Utilization: Idle / Low / Moderate / High / Saturated
Data Compressibility: Poor / Fair / Good / Excellent
Latency Sensitivity: Batch / Interactive / Real-time
I/O Pattern: Sequential / Random / Mixed

Workload Profiles and Recommendations
Profile	Characteristics	Recommendation
Desktop/Browser	Moderate memory, low CPU, good compressibility, interactive	Enable zswap or zram, LZ4, moderate pool
Database Server	High memory, moderate CPU, fair compressibility, latency-sensitive	Cautious: test thoroughly, consider LZ4 only
Build Server	Variable pressure, high CPU peaks, good compressibility, batch	Disable during builds, enable at idle
Container Host	Overcommit needed, moderate CPU, variable compressibility	zram per container or host zswap
ML Training	High memory, saturated CPU, poor compressibility (floats)	Likely disable; CPU too precious
Java Application	High heap, GC pauses, good compressibility	Enable cautiously; monitor GC impact
File Server	Cache-heavy, low CPU, filesystem already compressed	Minimal benefit; skip compression
Embedded System	Fixed memory, low CPU, variable data	zram with small pool; saves flash writes

Decision Framework:

Converting Mermaid diagram...

Adaptive Approaches

Benchmarking Methodology

Effective benchmarking requires measuring the right metrics under realistic conditions. Here's a systematic approach:

Key Metrics to Measure:

Application performance — Throughput, latency, response time
Memory efficiency — Working set size, compression ratio, pool usage
CPU overhead — Compression-related CPU time
I/O reduction — Swap read/write IOPS, bandwidth
Tail latency — P95, P99 response times

Benchmarking Protocol:

Benchmarking Steps

•Establish baseline — Run workload WITHOUT compression, record all metrics
•Enable compression — Configure zswap or zram with default settings
•Run identical workload — Same duration, same input, same conditions
•Record all metrics — Application AND system metrics
•Vary configuration — Test different algorithms, pool sizes
•Analyze tradeoffs — Compare application performance vs overhead
•Stress test — Push memory to 90%+, observe behavior under pressure
•Validate conclusions — Multiple runs, statistical significance

compression_benchmark.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
#!/bin/bash
# Comprehensive compression benchmarking script
 
WORKLOAD="$1"  # Command to run as workload
DURATION="${2:- 60
                        }"  # Seconds to run
OUTPUT_DIR = "${3:-./benchmark_results}"
 
mkdir - p "$OUTPUT_DIR"
 
run_benchmark() {
                            local name="$1"
    local config="$2"
    
    echo "=== Running benchmark: $name ==="
    
    # Apply configuration
    eval "$config"
    
    # Clear caches
    sync && echo 3 > /proc/sys / vm / drop_caches
    
    # Start monitoring
    vmstat 1 > "$OUTPUT_DIR/${name}_vmstat.log" &
                        VMSTAT_PID=$!
    
    sar - r 1 > "$OUTPUT_DIR/${name}_memory.log" 2 >& 1 &
                        SAR_PID=$!
    
    # Record start stats
    cat / sys / kernel / debug / zswap/* > "$OUTPUT_DIR/${name}_zswap_start.txt" 2>/dev/null
    cat /sys/block/zram0/mm_stat > "$OUTPUT_DIR/${name}_zram_start.txt" 2>/dev/null
    
    # Run workload with timing
    START_TIME=$(date +%s.%N)
    eval "$WORKLOAD" > "$OUTPUT_DIR/${name}_workload.log" 2>&1
    END_TIME=$(date +%s.%N)
    
    # Record end stats
    cat /sys/kernel/debug/zswap/* > "$OUTPUT_DIR/${name}_zswap_end.txt" 2>/dev/null
    cat /sys/block/zram0/mm_stat > "$OUTPUT_DIR/${name}_zram_end.txt" 2>/dev/null
    
    # Stop monitoring
    kill $VMSTAT_PID $SAR_PID 2>/dev/null
    
    # Calculate metrics
    ELAPSED=$(echo "$END_TIME - $START_TIME" | bc)
    echo "  Elapsed time: ${ELAPSED}s"
    
    # Parse swap I/O from vmstat
    SWAP_IN=$(awk 'NR>2 {sum+=$7} END {print sum}' "$OUTPUT_DIR/${name}_vmstat.log")
    SWAP_OUT=$(awk 'NR>2 {sum+=$8} END {print sum}' "$OUTPUT_DIR/${name}_vmstat.log")
    echo "  Swap in pages: $SWAP_IN"
    echo "  Swap out pages: $SWAP_OUT"
    
    # Record summary
    cat >> "$OUTPUT_DIR/summary.csv" <<EOF
$name,$ELAPSED,$SWAP_IN,$SWAP_OUT
EOF
}
 
# Initialize summary
echo "config,elapsed_time,swap_in,swap_out" > "$OUTPUT_DIR/summary.csv"
 
# Baseline: no compression
run_benchmark "no_compression" "
    swapoff /dev/zram0 2>/dev/null
    echo N > /sys/module/zswap/parameters/enabled
    swapon /dev/sda2  # Regular swap
"
 
# zswap with LZ4
run_benchmark "zswap_lz4" "
    swapoff /dev/zram0 2>/dev/null
    echo Y > /sys/module/zswap/parameters/enabled
    echo lz4 > /sys/module/zswap/parameters/compressor
    echo 25 > /sys/module/zswap/parameters/max_pool_percent
    swapon /dev/sda2
"
 
# zswap with Zstd
run_benchmark "zswap_zstd" "
    echo zstd > /sys/module/zswap/parameters/compressor
"
 
# zram with LZ4
run_benchmark "zram_lz4" "
    echo N > /sys/module/zswap/parameters/enabled
    swapoff -a
    modprobe zram
    echo 1 > /sys/block/zram0/reset
    echo lz4 > /sys/block/zram0/comp_algorithm
    echo 4G > /sys/block/zram0/disksize
    mkswap /dev/zram0
    swapon -p 100 /dev/zram0
"
 
echo ""
echo "=== Benchmark Complete ==="
echo "Results in: $OUTPUT_DIR"
cat "$OUTPUT_DIR/summary.csv"

Reproducibility

Tuning Strategies

Based on benchmarking results, apply targeted tuning to optimize for your specific workload:

Algorithm Tuning:

Goal	Action	Rationale
Minimize latency	Use LZ4	Fastest decompression
Maximize ratio	Use Zstd level 3	Best compression
Balance	Use LZO-RLE or Zstd-1	Moderate speed and ratio
Handle encrypted	Enable same-filled only	Skip compression, catch zeros

Pool Size Tuning:

Too small: High eviction rate → increased I/O → defeats purpose
Too large: Steals from application memory → may worsen pressure
Starting point: 20-25% of RAM
Adjust based on: Hit rate (higher = pool is working), eviction rate (lower = pool is sufficient)

Workload-Specific Tuning:

Latency-Sensitive Tuning

•Use LZ4 only
•Smaller pool (15-20%)
•Aggressive same-filled detection
•Consider priority-based compression
•Monitor P99 latency continuously

Memory-Critical Tuning

•Use Zstd for better ratio
•Larger pool (40-50%)
•Enable writeback if needed
•Tune zpool allocator (zsmalloc)
•Monitor compression ratio trends

tuning_recommendations.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#!/bin/bash
# Generate tuning recommendations based on metrics
 
echo "=== Compression Tuning Advisor ==="
echo ""
 
# Collect current metrics
if [ -d "/sys/kernel/debug/zswap" ]; then
    stored=$(cat /sys/kernel/debug/zswap/stored_pages 2>/dev/null || echo 0)
    pool_size=$(cat /sys/kernel/debug/zswap/pool_total_size 2>/dev/null || echo 0)
    reject_poor=$(cat /sys/kernel/debug/zswap/reject_compress_poor 2>/dev/null || echo 0)
    pool_limit=$(cat /sys/kernel/debug/zswap/pool_limit_hit 2>/dev/null || echo 0)
    written_back=$(cat /sys/kernel/debug/zswap/written_back_pages 2>/dev/null || echo 0)
    
    mem_total_kb=$(awk '/MemTotal/ {print $2}' /proc/meminfo)
    pool_pct=$((pool_size * 100 / (mem_total_kb * 1024)))
    
    echo "Current State:"
    echo "  Pool usage: ${pool_pct}% of RAM"
    echo "  Stored pages: $stored"
    echo "  Rejected (poor compression): $reject_poor"
    echo "  Pool limit hits: $pool_limit"
    echo "  Written back: $written_back"
    echo ""
    
    # Generate recommendations
    echo "Recommendations:"
    
    # Check rejection rate
    if [ "$stored" -gt 0 ]; then
        reject_rate=$((reject_poor * 100 / (stored + reject_poor)))
        if [ "$reject_rate" -gt 30 ]; then
            echo "  ⚠ High rejection rate (${reject_rate}%)"
            echo "    → Workload may have incompressible data"
            echo "    → Consider: LZ4 (faster bypass) or disable compression"
        fi
    fi
    
    # Check pool limit hits
    if [ "$pool_limit" -gt 0 ]; then
        echo "  ⚠ Pool limit was hit $pool_limit times"
        echo "    → Consider: Increase max_pool_percent"
        echo "    → Or: Enable writeback to backing device"
    fi
    
    # Check writeback activity
    if [ "$written_back" -gt 0 ] && [ "$stored" -gt 0 ]; then
        wb_rate=$((written_back * 100 / stored))
        if [ "$wb_rate" -gt 20 ]; then
            echo "  ⚠ High writeback rate (${wb_rate}%)"
            echo "    → Pool may be too small"
            echo "    → Consider: Increase pool size"
        fi
    fi
    
    # Pool size recommendations
    if [ "$pool_pct" -lt 15 ]; then
        echo "  💡 Pool is small (${pool_pct}%)"
        echo "    → May not be capturing full benefit"
        echo "    → Consider: Increase to 20-30%"
    elif [ "$pool_pct" -gt 50 ]; then
        echo "  💡 Pool is large (${pool_pct}%)"
        echo "    → May be starving applications"
        echo "    → Monitor application memory allocation failures"
    fi
    
    # Calculate compression ratio
    if [ "$pool_size" -gt 0 ] && [ "$stored" -gt 0 ]; then
        orig=$((stored * 4096))
        ratio=$(echo "scale=2; $orig / $pool_size" | bc)
        
        echo ""
        echo "Compression ratio: ${ratio}:1"
        
        if [ "$(echo "$ratio < 1.5" | bc)" -eq 1 ]; then
            echo "  ⚠ Low compression ratio"
            echo "    → Benefits may not justify overhead"
            echo "    → Consider: Disabling compression for this workload"
        elif [ "$(echo "$ratio > 3.0" | bc)" -eq 1 ]; then
            echo "  ✓ Excellent compression ratio"
            echo "    → Compression is very effective"
            echo "    → Consider: Larger pool to cache more"
        fi
    fi
    
else
    echo "zswap not enabled or debugfs not mounted"
fi
 
echo ""
echo "Run this script periodically during typical workload for best results."

Real-World Case Studies

Understanding how memory compression performs in real deployments provides practical insight. Here are documented case studies:

Case Study 1: Desktop Linux with Firefox/Chrome

Profile: 8GB RAM, heavy browser use (50+ tabs), moderate CPU usage

Metric	Without Compression	With zram (LZ4)
Tab switches	200-2000 ms	50-200 ms
System swap usage	2-4 GB	< 100 MB
Tab discards	Frequent	Rare
CPU overhead	-	0.5-1%

Conclusion: Dramatic improvement in responsiveness. Browser tab data compresses well (3:1+). LZ4 recommended for consistent low latency.

Case Study 2: Container Host with Memory Overcommit

Profile: 64GB host, 100 containers with 1GB limit each (100GB logical), variable workloads

Metric	Without Compression	With zswap (Zstd)
SSD swap I/O	50-200 MB/s	5-20 MB/s
Container OOM kills	5-10/day	1-2/day
P99 response time	500 ms	150 ms
CPU overhead	-	2-3%

Conclusion: 80% reduction in swap I/O enables higher container density. Zstd's better ratio justifies CPU cost in this scenario.

Case Study 3: Database Server (PostgreSQL)

Profile: 256GB RAM, PostgreSQL with 200GB shared buffers, complex queries

Metric	Without Compression	With zswap (LZ4)
Query latency P50	12 ms	13 ms (+8%)
Query latency P99	150 ms	180 ms (+20%)
Memory headroom	20 GB	45 GB
Emergency OOM events	Monthly	None

Case Study 4: ML Training (Encrypted Data)

Profile: GPU training with encrypted datasets

Metric	Without Compression	With zram
Training throughput	Baseline	-2%
GPU utilization	95%	93%
Compression ratio	-	1.05:1
CPU overhead	-	3%

Conclusion: Encrypted data doesn't compress. CPU overhead provides no benefit and slightly reduces GPU feed rate. Compression disabled for this workload.

Learn from Others, Validate for Yourself

Summary: Performance Tradeoffs

We've comprehensively explored the performance tradeoffs inherent in memory compression. Let's consolidate the essential understanding:

Key Takeaways

•Compression trades CPU for memory/I/O — This tradeoff is favorable when CPU is cheaper than what you're avoiding.
•Latency analysis reveals optimization opportunities — Know where time goes to know where to optimize.
•CPU overhead is usually modest — Typically 0.5-5% even under pressure; thrashing is the exception.
•Memory efficiency depends on workload — Measure actual compression ratio, not theoretical maximum.
•Classify your workload first — Different profiles require different strategies.
•Benchmark systematically — Control variables, measure the right metrics, validate conclusions.
•Tune iteratively — Start with defaults, adjust based on observed behavior.
•Real-world experience guides — Learn from case studies, but validate for your specific situation.

Final Recommendation:

Module Complete