15 comments

[ 3.3 ms ] story [ 42.3 ms ] thread
a comment here about zram caught my eye a day or two ago and I've been meaning to look into it. Glad to see this post (and I'm sure many others saw the same comment and shared my obsession)
This post’s conclusions are odd. It has a bunch of extensive benchmarks showing that zstd is by far the worst performing across every metric except a slight increase in compression ratio and then says the conclusion is zstd is the best choice. Unless I’m missing something in the data.
Has anyone tried using zram inside of various K8s pods? If so, I'd be interested in knowing the outcome.
Inside the pods it makes no sense, but I do enable it on some memory-constrained worker nodes. Note that the kubelet by default refuses to start if the machine has any swap at all.
Just I was trying to find a benchmark about this, I wondered which algorithm would work best for videogames. Thanks!
Video games and compute heavy tasks cannot have a large compression factor. The good thing is that you can test your own setup using zramctl.
zram tends to change the calculus of how to setup the memory behavior of your kernel.

On a system with integrated graphics and 8 (16 logical) cores and 32 GB of system memory I achieve what appears to be optimal performance using:

    zramen --algorithm zstd --size 200 --priority 100 --max-size 131072 make
    sysctl vm.swappiness=180
    sysctl vm.page-cluster=0
    sysctl vm.vfs_cache_pressure=200
    sysctl vm.dirty_background_ratio=1
    sysctl vm.dirty_ratio=2
    sysctl vm.watermark_boost_factor=0
    sysctl vm.watermark_scale_factor=125
    sysctl kernel.nmi_watchdog=0
    sysctl vm.min_free_kbytes=150000
    sysctl vm.dirty_expire_centisecs=1500
    sysctl vm.dirty_writeback_centisecs=1500
Compression factor tends to stay above 3.0. At very little cost I more than doubled my effective system memory. If an individual workload uses a significant fraction of system memory at once complications may arise.
(comment deleted)
LZ4 looks like the sweet spot to me, you get OK compression and the performance hit is minimal.
This seems like a great place to ask: how does one go about optimizing something like zram, which has a tremendous number of parameters [1]?

I had considered some kind of test where each parameter is perturbed a bit in sequence, so that you get an estimate of a point partial derivative. You would then do an iterative hill climb. That probably won't work well in my case since the devices I'm optimizing have too much variance to give a clear signal on benchmarks of a reasonable duration.

[1] https://docs.kernel.org/admin-guide/sysctl/vm.html

you have have multiple layers of compression, but you need some simple Daemon (basically for loop in bash)

I use lz4-rle as first layer, but if page is idle for 1h it is recompressed using zstd lvl 22 in the background

it is great balance, for responsiveness Vs compression ratio