An unofficial Debian Installer for Pinebook Pro

[moonwalkers]

Memory filesystem


If I recall correctly, Manjaro sets up several memory filesystems. Any thoughts on introducing memory filesystems for /tmp and friends on our Debian builds?

The plus: Less flash wear.

The minus: on a memory constrained system such as the Pinebook Pro (and in particular in combination with 64bit binaries) this might result in more paging.


Note: When I was running Manjaro for some time, emacs's cscope mode was requesting more space in /tmp than what was configured. So, with a conservative /tmp size, we may run into problems from time to time.

I've been very successful with implementing zram-swap, as outlined here zram swap support for the PBP; aka: "how to download more RAM" by  @"Arglebargle"  

On the PBP, with Bullseye at least, this is not without minor problems. It causes lsblk to hang, which interrupts common operations, like updating initramfs from apt/dpkg/etc. I worked around this by manually turning off swaps and unloading the module for these tasks.

Otherwise, zram-swap should be almost considered for default, as it addresses your concerns about solid-state storage wear and swappiness - while increasing functional RAM availability. Android has this standard for years, and little wonder, considering the target devices and their use cases.

Just out of interest, did you have problems with the default zswap based approach?

Out-of-the-box the installer should already support compressed in-memory swap but it will use zswap rather than zram. In other words the compressed in-memory swap is preferred but when things get difficult it is reinforced by having a real swap partition as well. The idea is that some processes cause pages to be mapped but then never really use them. Thus a system under memory pressure benefits from getting this rarely or never used data out to disk... I suspect this is true even on systems based on eMMC which is why I adopted zswap by default. I hoped it would be in the "Goldilocks zone" between excessive flash wear and poor system behaviour under memory pressure (zram works well for Android because they can nuke background apps but there is not framework to make correct decisions about what to kill on a full Linux system so it is more important to avoid the OoM killer).

BTW I'm still trying to discover the most "Debian" way to enable ram based tmpfs but the follow looks like it will restore the systemd default behaviour and establish a ram based tmpfs (the Debian maintainers explicitly override this default to make sure it never turns on without the user requesting it):

Code:

sudo cp /usr/share/systemd/tmp.mount /etc/systemd/system/

---

Sorry... above please s/swap partition/swap file/ but otherwise its all good ;-)

I've used a rather resource constrained machine (Core 2 Duo with 4GiB RAM and SATA II SSD) as my daily driver for over a year. I don't have precise benchmarks, but in my experience no matter the tuning I've done zram was resulting in a more responsive system than zswap. My understanding of the reason for that is that zram has a fixed size of its virtual block device, but if the data in there is highly compressible it'll take very little ram (you can actually see those stats if you run zramctl, 'sudo zramctl' in Debian). So unless you need to swap you will use no additional CPU or RAM. Because of that I can typically create a virtual zram block device that's as big if not bigger than the amount of RAM I have. At work for our fleet we set 1.5*RAM, on my personal machines I set 2*RAM and the only time I've seen issues is with apps that seriously overcommit the memory or with things like downloading large incompressible file from mega.nz using Firefox instead of Chrome. zswap on the other hand uses a fixed amount of RAM, IIRC, and then if the memory pressure becomes high enough for it to dump pages to on-disk swap it will first decompress them (+CPU usage), and then dump them on disk uncompressed (+I/O). So in my experience zswap is only good if you have moderate to low memory pressure, but if you're in a medium-high memory pressure you're better off with zram, and if zram is inadequate (you need to cram way too much into RAM, more than 2-2.5xRAM) then you're better off giving up on any RAM compression techniques and just doing the old-school on-disk swap, where you can have some scripts that dynamically allocate extra swap space based on the need.

Currently I use zram with my PBP, though instead of complex script described in the neighboring topic I just have zram in /etc/modules-load.d/, zram line in /etc/fstab, and the following line in udev rules:

Code:

KERNEL=="zram0", SUBSYSTEM=="block", ACTION=="add", ATTR{initstate}=="0", PROGRAM="/bin/sh -c 'echo $(($(LANG=C free -k | grep -e \"^Mem:\" | sed -e \"s/^Mem: *//\" -e \"s/  *.*//\")*2))KiB'", ATTR{disksize}="$result", RUN+="/sbin/mkswap $env{DEVNAME}", TAG+="systemd"

The script could use some refinement, in fact IIRC I do have a more refined version we use in our fleet, but I was too lazy to copy it back to my machine.