I posted about ZRAM before, but because of my totally unscientific experiment, personal experience and the common question, which Linux to run on potatoes…

First, I tweaked ZRAM for my use-case(s) on my hardware, this settings might not be right for your use-cases or your hardware!

My hardware is a netbook with an Intel Celeron N4120 and 4G RAM (3.64G usable).

When I recently played around with ZRAM settings, it felt like the zstd algorithm made my netbook noticeable more sluggish. It never felt sluggish with lzo-rle or lz4.

In a totally unscientific way, I rebooted the computer several times (after a complete update of everything), executed my backup script several times, and measured the last 3 executions. (Didn’t touch the netbook during the runs.) The bottleneck of the backup script should not be ZRAM, but it is some reproducible workload that I could execute and measure.

To my surprise, I could measure a performance difference for my backup scripts, lz4 was consistent fastest in real and sys time w/o tweaks to vm.page-cluster!

Changing the vm.page-cluster to 0 further enhanced the speed for lz4, but with this one toggle, all of a sudden zstd is as fast as lz4 in my benchmark and runs with a more consistent runtime.

Changing the vm.swapiness to 180 decreased the speed for lz4, to my surprise.

Obviously the benchmarks are not 100% clean, although the trend for my workload was clearly in favor of lz4/zstd.

To the best of my knowledge, I ended up with nearly the same tweaks that Google makes for ChromeOS:

  • zstd as algorithm (I think ChromeOS uses lzo-rle)

  • 2*ram as ram-size

  • vm.page-cluster = 0

  • Install/enable systemd-oomd

vm.page-cluster = 0 seems like a no-brainer when using ZRAM, on my netbook it is literally the switch for ‘fast’ mode.

In summary: ZRAM makes my netbook totally usable for everyday tasks, and with tweaking the above settings I run Gnome 3, VS Code and Firefox/Evolution w/o trouble. (Of course, Xfce4 on the same machine is still noticeable more performant.)

I wonder if we should recommend to people asking for a lightweight distribution for potatoes to check/tweak their ZRAM settings by default.

Anyway, I would be interested in experiences from other people:

  1. Any other tweaks on my ZRAM or sysctl for potatoes which made a measurable difference for you?
  2. Any other tips to improve quality of life on potatoe machines? (Besides switching to KDE, LXDE, Xfce, etc. ;-))
  3. Any idea why vm.swapiness didn’t improve my measurements? To my understanding it should basically have cached more of my files in ZRAM, making the backup run faster. It even slowed the backup down, which I don’t understand.

Edit:

  • zstd beats lz4 on my machine for my benchmark when vm.page-cluster=0!
  • wolf@lemmy.zipOPEnglish
    1·
    3 months ago

    Thanks a lot! You are right, I saw this already.

    I can confirm the findings with my benchmarks: zstd has the best compression, lz4 is the fastest.

    • Samueru
      2·
      3 months ago

      Here is what I ended up using for my sysctl conf, iirc I got some of these from popos default config:

      vm.swappiness = 180
vm.page-cluster = 0
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.dirty_bytes = 268435456
vm.dirty_background_bytes = 134217728
vm.max_map_count = 2147483642
vm.dirtytime_expire_seconds = 1800
vm.transparent_hugepages = madvise
      • wolf@lemmy.zipOPEnglish
        1·
        3 months ago

        Could you ELI5 the last five settings? I saw that Chrome OS sets vm.overcommit_memory = 1, it seems to make sense but is missing here.

        • Samueru
          2·
          3 months ago

          I really don’t know lol

          Increasing the max_map_count is needed for some Steam games, iirc Arch is now dong this by default.

          iirc the dirty_bytes settings prevent the system from hanging if there is too much disk IO

          And setting transparent_hugepages to madvise was something I did when archlinux had this bug in the kernel: https://old.reddit.com/r/archlinux/comments/1atueo0/higher_ram_usage_since_kernel_67_and_the_solution/

          It was eventually fixed but I later ran into the issue again and I decided to keep it on madvise.

          • wolf@lemmy.zipOPEnglish
            2·
            3 months ago

            Nice, thanks a lot, especially the dirty_bytes settings are interesting to me, because I experience hangs with too much disk IO :-P.

            Cheers!