No swap or zram on a 3.5 GiB board #13

Closed
opened 2026-08-27 23:22:25 +00:00 by tiagoagueda · 1 comment
Owner

free reports 3471 MiB RAM and 0 MiB swap. There is no margin: one greedy process
takes 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

  • zram configured and sized
  • behaviour under memory pressure sanity-checked
`free` reports 3471 MiB RAM and **0 MiB swap**. There is no margin: one greedy process takes 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** - [ ] zram configured and sized - [ ] behaviour under memory pressure sanity-checked
Author
Owner

Done — zram in the kernel, with an eMMC swapfile behind it

CONFIG_ZRAM was 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/modules holds directories for two older kernels and none for the running one, and deploy-kernel.sh never installs modules — so modprobe cannot work here. Anything shipped as =m would simply not load. (That gap is real and belongs in #8; it is also why the rescue card's initramfs builds with modules.builtin warnings.)

Now running 7.2.0-14857-g0a8c6926d04f:

NAME       TYPE       SIZE USED PRIO
/dev/zram0 partition  1.7G   0B  100
/swapfile  file      1024M   0B   10
Swap:  2759 MiB total   (was 0)

Two tiers on purpose. zram is ram / 2 with zstd, at priority 100 — it lives in RAM, compresses roughly 3×, and costs no flash. The 1 GiB eMMC /swapfile sits behind it at priority 10 purely as an OOM backstop, so only a genuinely large overcommit ever touches flash. vm.swappiness = 100 because the first tier is memory, not disk, and vm.page-cluster = 0 because readahead is pointless for zram.

Also fixed along the way: the tracked patches/configs/draco_linux_defconfig was stale by much more than zram — it was missing CONFIG_HIGHMEM and CONFIG_ARM_LPAE, so anyone rebuilding from it would have produced a kernel unable to address the board's 3.5 GiB. Regenerated with savedefconfig.

## Done — zram in the kernel, with an eMMC swapfile behind it `CONFIG_ZRAM` was 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/modules` holds directories for two older kernels and none for the running one, and `deploy-kernel.sh` never installs modules — so `modprobe` cannot work here. Anything shipped as `=m` would simply not load. (That gap is real and belongs in #8; it is also why the rescue card's initramfs builds with `modules.builtin` warnings.) Now running `7.2.0-14857-g0a8c6926d04f`: ``` NAME TYPE SIZE USED PRIO /dev/zram0 partition 1.7G 0B 100 /swapfile file 1024M 0B 10 Swap: 2759 MiB total (was 0) ``` Two tiers on purpose. zram is `ram / 2` with **zstd**, at priority 100 — it lives in RAM, compresses roughly 3×, and costs no flash. The 1 GiB eMMC `/swapfile` sits behind it at priority 10 purely as an OOM backstop, so only a genuinely large overcommit ever touches flash. `vm.swappiness = 100` because the first tier is memory, not disk, and `vm.page-cluster = 0` because readahead is pointless for zram. Also fixed along the way: **the tracked `patches/configs/draco_linux_defconfig` was stale by much more than zram** — it was missing `CONFIG_HIGHMEM` and `CONFIG_ARM_LPAE`, so anyone rebuilding from it would have produced a kernel unable to address the board's 3.5 GiB. Regenerated with `savedefconfig`.
Sign in to join this conversation.
No description provided.