@
arglebargle have to totally agree its totally mystifying how the ubuntu zram-conf script has been emulated and copied so many times whilst in many respects its broken.
Google have it about right with 3:1 but the choice of alg is yours as Zstd garners much better compression for a higher cpu hit.
Disk size in zram is this strange virtual size that has no control over actual ram usage as it is possible to get much lower compression on already compressed input and ram usage can spiral or you limit the usefulness of disk size by reducing.
For sys-admins zram does have a mem_limit directive that most scripts miss where you can define max actual ram usage and just creating large disksizes that will never be used isn't a good idea as even when empty they can have an overhead of approx "zram uses about 0.1% of the size of the disk when not in use so a huge zram is wasteful"
Often scripts pointlessly ignore that zram has been multi-stream since kernel 3.15 and pointless make smaller multiple zram device.
To say zswap avoids the LRU inversion problem is a bit like comparing apples and pears because as far as I am aware there isn't a single script that employs the write back policy of zram.
I think I am right in saying that Google tweak swapiness and page-cache where swappiness is much higher as its not disk based but near memcpy speed compressed memory and also page-cache is set to zero for single pages rather than the default cache buffer of 8.
This makes sense as swap is no longer disk based its mem based and has very different working parameters.
I use zram because a SD card swap just doesn't make sense and in my application I would never use the write back cache with zram. I actually did read
https://www.kernel.org/doc/Documentation/blockdev/zram.txt implemented many of its methods but the write back cache just didn't make sense it just seems to be an after thought and poorly implemented and not needed.
StuartIanNaylor/zram-config does far more than just zswap though as in certain applications high speed zram based drives can increase performance or can be used to mitigate nand block wear.
In the embedded space a zlog for SD based systems with high write count can extend SD lifetime extensively.
You can even use zram in an upper RW mount of a OverlayFS and create an emphemeral kiosk device that will always revert on reboot with zero writes to nand or zdir where sync back to persistent only happens on stop.
zram & zswap are apples & pears and in usage there is no LRU inversion problem because practically no-one employs the write back cache.
I am still interested in zswap as the use of a smaller zswap cache infront of a file based swap on f2fs could be interesting on faster flash than SD card and cause much less block wear to nand and giving more usage.
But for many with lzo/4 and the upcoming lzo-rle extremely fast near memcpy swap can be achieved with a 300% gain on the ram it uses.
Zstd as said could push that to 400% and with directories containing text much higher ratio's can be expected.
pi@raspberrypi:~ $ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4 1.2G 4K 76B 4K 4 [SWAP]
/dev/zram1 lz4 150M 16.3M 25.1K 208K 4 /opt/zram/zram1
/dev/zram2 lz4 60M 7.5M 1.2M 1.7M 4 /opt/zram/zram2
The above from my lowly Pi3 but zram-config or any of the utils such as
StuartIanNaylor/zramdrive or
StuartIanNaylor/log2zram could be used on any architecture.
With zram and zswap are not like for like and highly likely not going to be employed for the same working parameters. One isn't better than the other but disk based swap of any sort is generally a last resort and not a solution as when pushed things generally start to grind to a halt.
With high levels of concurrency and latent pages maybe swap is a better option whilst in a performance scenario running non disk based zram could be a better solution.
The scripts that are generally available for zram make very little sense if you actually take the time to read
https://www.kernel.org/doc/Documentation/blockdev/zram.txt