I know the Raspberry engineers had a look and decided not to go with zram probably as it was the time of the original Pi.
If you use a Pi Zero you can really start to notice zram when swappiness is above the default of 60.
Pi2 there is far more IO wait than process wait and Zram on a Pi3/+ works really well.
I think they looked at effect on boot of original models and went against the idea and that is now sort of set in stone in as a Raspberry foundation.
I think they might reevaluate as even on a zero it works well as with most applications don't have anywhere near the constant load that boot does, its just the intense boot of the pi zero where zram load increases overall load.
When I was playing purely with swaps I did a rough and ready with https://github.com/StuartIanNaylor/zram ... d-balancer
As it increases swapiness after load starts to stabilise and overall loadavg does drop.
https://github.com/StuartIanNaylor/zram ... d-balancer
was just a rough and ready with using a pi-zero and you can change swapinness and so effect how much swap is used and the load incurred by zram.
Also zram for some reason just got labelled with swaps as it can make extremely fast zram disks compared to sd-media and with the compression that from usage is approx 300%+ with LZ4 even with meagre resources there are a lot uses.
Logs are not the only thing that can write heavily and sd block wear isn't the only use as near memcpy disk storage can be used and then shipped to persistent on stop as say with Samba maybe /var/cache would benefit of residing on zram.
A lot of what is said about Micro SD is pure hocus and it was designed for storage and reading rather than constant writes and still is.
Most applications we don't need to bother and SD cards are so cheap who really cares.
In some applications the cost of access and maintenance to a failed SD card is far more than the couple of $/£ of a replacement card.
The Pi when it comes to swap in default offering with the 100m dphys-swap is bemusing to say the least and the Raspibian engineers also decided to dodge f2fs Flash-Friendly File System which probably wise at the time but maybe especially as the PI has become more powerful that zram and f2fs, but maybe they might be reevaluated.
f2fs got a lot of commits in kernel 4.18 so with Raspbian Buster (4.19) prob months away I have also been looking at f2fs as like Pi's getting faster the price and size of SD cards has also vastly changed since 2012.
Buster also includes the Zstd compression alg that has amazing text compression ratio's, but generally beats Zlib on compression ratio whilst providing near LZO speed. Zstd for Zdir is likely to make an extremely good candidate.
I did try with the testing version of Buster with f2fs as f2fs tries to serialise writes and minimise and also supports a native over-provision that is block-wear and large write quantity over a long period where a concern you could just go crazy with a 100% over-provision and essentially double life expectancy as the volume will remain 100% available by just allocating what is often spare to the over provision.
It doesn't just have to be zram but yeah maybe Raspberry might think of a new raspi-config entry that allows any device to bind more easily with the current dir structure.
If f2fs is of interest there is a ready img here any can play with as a precursor to buster. https://1drv.ms/u/s!AocmAh35i26QiB7pE5qZnfFyi4Iq
I know the image is ArchV7 but its 4.19 currently so its been handy as I am trying to decide whether to offer f2fs bind mounts or make a utility to resize a card and provide native f2fs for /var and /opt and thinking probably the latter as a zswap f2fs dphy-swap file is also an interesting option.