I’ve been experimenting with ZRAM optimization on the Sony Xperia 10 III running SailfishOS, and I ended up creating a small workaround that allows you to:
increase ZRAM size (in my case, 4 GB)
set a custom compression algorithm
adjust swap priority
enforce a final swappiness value
and make everything persistent through a systemd service
I wrote a complete guide on GitHub, including the script and the systemd unit.
The workaround has been tested on SailfishOS 5.0.0.72 in Sony Xperia 10 III, but with a few adjustments (for example: never setting ZRAM larger than the device’s physical RAM), it should be potentially applicable to any SailfishOS device — of course at your own risk.
The goal of this setup is to increase performance and to give users more control over how ZRAM is configured and to override the early-boot settings applied by droid-hal. If you’re curious about how ZRAM, swap priority, and swappiness interact on SailfishOS, the guide may be useful.
Feedback, improvements, and testing on other devices are very welcome.
ho sperimentato un po’ con l’ottimizzazione di ZRAM sul Sony Xperia 10 III con SailfishOS, e alla fine ho realizzato un piccolo workaround che permette di:
aumentare la dimensione della ZRAM (nel mio caso, 4 GB)
impostare un algoritmo di compressione personalizzato
regolare la priorità dello swap
forzare un valore finale di swappiness
rendere tutto persistente tramite un servizio systemd
Ho scritto una guida completa su GitHub, che include sia lo script sia l’unità systemd.
Il workaround è stato testato su SailfishOS 5.0.0.72 su Sony Xperia 10 III, ma con qualche modifica (ad esempio: non impostare mai una ZRAM più grande della RAM fisica del dispositivo) dovrebbe essere potenzialmente applicabile a qualsiasi dispositivo SailfishOS — naturalmente a proprio rischio e pericolo.
L’obiettivo di questa configurazione è migliorare le prestazioni del dispositivo e dare agli utenti un maggiore controllo su come ZRAM viene configurata, oltre a permettere di sovrascrivere i parametri impostati molto presto nel boot da droid-hal. Se siete curiosi di capire come interagiscono ZRAM, priorità dello swap e swappiness su SailfishOS, la guida potrebbe esservi utile.
Feedback, suggerimenti e test su altri dispositivi sono più che benvenuti.
why such low swapiness value?
because some sources tend to go the opposite way if using zram (high swapiness), e.g. https://wiki.archlinux.org/title/Zram
default value on my phone is also very high
[defaultuser@Fairphone4 ~]$ sysctl -a | grep swap
vm.kswapd_threads = 1
vm.swap_ratio = 100
vm.swap_ratio_enable = 0
vm.swappiness = 100
# but not much used
[defaultuser@Fairphone4 ~]$ free -m
total used free shared buff/cache available
Mem: 5503 2123 616 333 2764 3655
Swap: 3072 323 2749
AI ANSWER:
Here’s the key point: the ideal swappiness value depends heavily on the type of device and on how its memory management works.
On Linux servers, where CPUs are powerful, RAM is abundant, and workloads are predictable, a high swappiness value (60–100) is often ideal. It maximizes throughput and allows the kernel to use swap as a natural extension of memory. Latency is not a critical concern, so higher values work well.
On Linux desktops, the priority is keeping the user interface responsive. For this reason, many users prefer very low values, such as: vm.swappiness = 10
This ensures that swap is used only when truly necessary, avoiding lag caused by compression/decompression or page movement.
SailfishOS devices, which rely on the Android HAL memory layer, behave more like desktops than servers:
Android HAL tends to kill background processes rather than swap aggressively
even with swappiness=100, swap usage often stays low
mobile CPUs pay a higher cost for compression/decompression
UI responsiveness is more important than raw throughput
For these reasons, a low swappiness value (10–30) is generally more balanced. In my case, I chose 20, which keeps ZRAM as a safety buffer instead of turning it into the primary memory extension.
In summary:
Linux servers → high swappiness (60–100)
Linux desktops → low swappiness (10–20)
SailfishOS smartphones → low swappiness (10–30)
So yes, high values make sense in some contexts, but on SailfishOS smartphones a conservative value like 20 tends to provide a more stable and responsive experience.
I’m italian, it’s very difficult for me answer clearly in english, so yes, I have used AI for answer, but the concept is that. I have always use low swappiness on my desktop/laptop and high value on my server.
I will try it. However the concept of swappiness is simple: low value = priority to read and write on phisycal RAM, high value = priority to compress data in ZRAM.
So, in a device that needs reactivity, low swappiness is preferred.
It’s not like the AI is clear either - it adds so much useless fluff. But at least you can know what you want to say - it just puts up random plausible/related stuff.
My workaround is highly customizable, if you like an high swappiness you can set it. But, in my honest opinion, low swappiness is better if you use a device like NOT a server.
With swappiness=100: when the kernel decides to reclaim memory, it is allowed to swap out pages more aggressively, but the kernel will always try to use RAM first, because RAM is faster than ZRAM and ZRAM is faster than disk swap. So even with swappppiness=100 Linux still fills RAM before swapping. Swappiness affects WHEN swapping happens, not the basic rule that RAM is always used first.
With swappiness=10 the system will use ZRAM ONLY if RAM is full at around 90%.
With high swappiness: ZRAM kicks in as soon as the system feels some memory pressure, and this can increase latency on mobile CPUs because of continuous compression and decompression.
With low swappiness: the system tries to avoid swapping as much as possible and will therefore use ZRAM only when RAM is really under heavy pressure (almost full). This helps maintain better responsiveness because the CPU stays free more often.
There is one thing that bothers me, what is the reason to increase zram if you are decrasing swappines to not use it? It does not make any logical sense. If you try avoid zram you should increase available RAM.
Please do not share curl | bash commands here.
Some newbie might take you up on it and actually do that on their phone.
During our discussion here it became clear that you yourself are aware that you aren’t 100% sure about how exactly each of these settings affects each different phone.
Also, through your username you basically admit to using AI and that makes me doubly uncomfortable.
Increasing ZRAM provides more fast virtual memory and helps avoid OOM (Out Of Memory situations, where the kernel would otherwise need to kill various processes). Lowering swappiness does not disable ZRAM, it simply prevents the kernel from swapping too early. This way, real RAM is used to its fullest, and ZRAM kicks in only when it’s genuinely needed.
It’s a balance between performance and stability, not a contradiction.
I’ve spent a lot of time experimenting with ZRAM configurations on Linux to find the best setup. In the end, for a responsive system, I’ve always preferred ZRAM equal to RAM (or slightly less) combined with low swappiness.
I’m not forcing anyone to use my configuration choices — the script is open and easily adjustable to personal needs. For example, someone using their smartphone as a server (a friend of mine does this) might actually benefit from a higher swappiness value.
