(01-30-2020, 02:35 PM)Jeremiah Cornelius Wrote:(01-30-2020, 12:59 PM)Der Geist der Maschine Wrote: 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 ;-)