No swap or zram on a 3.5 GiB board #13
Labels
No labels
blocked-physical
cleanup
hardware
infra
kernel
P1-critical
P2-high
P3-normal
P4-later
reliability
security
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tiagoagueda/a80#13
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
freereports 3471 MiB RAM and 0 MiB swap. There is no margin: one greedy processtakes the board down, and on a headless host with no remote power that is an outage requiring
a visit.
zram is the right answer here rather than a swap file — it costs no eMMC writes, and eMMC wear
is the one thing on this board that cannot be replaced.
Done when
Done — zram in the kernel, with an eMMC swapfile behind it
CONFIG_ZRAMwas not set, so this needed a kernel rebuild. Built in rather than as a module, and that choice is worth explaining: this board has no working module tree at all./lib/modulesholds directories for two older kernels and none for the running one, anddeploy-kernel.shnever installs modules — somodprobecannot work here. Anything shipped as=mwould simply not load. (That gap is real and belongs in #8; it is also why the rescue card's initramfs builds withmodules.builtinwarnings.)Now running
7.2.0-14857-g0a8c6926d04f:Two tiers on purpose. zram is
ram / 2with zstd, at priority 100 — it lives in RAM, compresses roughly 3×, and costs no flash. The 1 GiB eMMC/swapfilesits behind it at priority 10 purely as an OOM backstop, so only a genuinely large overcommit ever touches flash.vm.swappiness = 100because the first tier is memory, not disk, andvm.page-cluster = 0because readahead is pointless for zram.Also fixed along the way: the tracked
patches/configs/draco_linux_defconfigwas stale by much more than zram — it was missingCONFIG_HIGHMEMandCONFIG_ARM_LPAE, so anyone rebuilding from it would have produced a kernel unable to address the board's 3.5 GiB. Regenerated withsavedefconfig.