Did need to run this after setting up, otherwise it showed 0GB:
zramctl --reset /dev/zram0
zramctl --find --size 2G
mkswap /dev/zram0

This is weird. Why not just compress less used areas of RAM (like, for example, macOS does)? Swapping to compressed RAM seems stupidly excessive.

@Greg A. Woods not sure if we are talking about two different things here? This has nothing to do with available or free RAM, it is compressing what would have been written out to a swap file on the drive, to a compressed area of RAM instead. It is way faster than writing to the drive.

Exactly -- but it goes through the motions and overhead of "swapping/paging".

Other systems, including macOS, just compress areas of RAM directly in place and thus can re-use the resulting "free" memory without having to pretend to swap/page to a different device.

There's bookkeeping overhead in both schemes of course, but there's no overhead of a simulated device in compressed RAM, whereas there is with ZRAM.

swap is used when ram is not sufficient.. use ram for swap is just like ...

KiB Mem : 8066012 total, 3544108 free, 1457188 used, 3064716 buff/cache
KiB Swap: 15624188 total, 15624188 free, 0 used. 6083528 avail Mem

Well ZRAM compresses whatever's stored in it, which is in effect a way to give you more storage, BUT for the overhead of the swapping/paging activity and the pseudo-device it requires everything to be funnelled through.

With directly compressed memory you don't have to move the data twice through the internal device interfaces and APIs, and I think the bookkeeping might actually be simpler. You might have to uncompress to a different area, but that just requires changing a page table entry.

Fact is swapping to SSD drives can speed up their demise and destroy ssd such a bad future

i can't imagine swap to ssd...SDD + HDD or nmve + hdd but i will not buy a ssd only computer... my home computer is 3 disk :
1 nmve + 2 hdd
nmve is system, one hdd is home, the other one is var + swap + tmp

👍 @Greg A. Woods

Found in my MX repository

zram is a Linux kernel module that allows you to set up compressed
filesystems in RAM.
zram-tools uses this module to set up compressed swap space.
This is useful on systems with low memory or servers
running a large amount of services with data that's easily swappable
but that you may wish to swap back fast without sacrificing disk
bandwidth.
By default it allocates 100MB of RAM, you can configure this in
/etc/default/zramswap.

I re-share for further investigations... :-)

@Greg A. Woods @herve_02@diasp.org

SwapOnZRAM

significantly improves system responsiveness, especially when swap is under pressure;
more secure, user data leaks into swap are on volatile media;
without swap-on-drive, there's better utilization of a limited resource: benefit of swap without the drive space consumption;
complements on-going resource control work, including earlyoom;
further reduces the time to out-of-memory kill, when workloads exceed limits;
improves performance for both "no swap" and "existing swap" setups;

https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Benefit_to_Fedora

@redj 18 thanks yes and note they have zram and zswap. Latter one being a compressed swap file on disk. By default it activates both and gives preference to the swap file. Apparently you can change the preference to using the zram first. It also has a means to send what can be compressed to zram, and what cannot be compressed gets sent to zswap.

But I opted to disable the zswap and only use zram. I used the zram-generator application with it's single config file. But I had issues and realised later it was because I did not comment out the mount point line, it was trying to create a mount point and failing, and hence why my zram was also not coming up properly. After commenting that line out seems to now be working fine after rebooting.

The documentation everywhere for this just leaves a bit wanting... maybe it's just me but I was a bit disappointed. I just feel the zram-generator config file could have expanded quite a bit more on each option and why etc.

I didn't say ZRAM wouldn't improve system performance in some ways in some circumstances. 🙂

However it's a poor and less than ideal design when considered for the purpose of a swapping/paging device (except maybe in a very few, very specific, circumstances). Basically it's a cheap hack that has some benefit, but isn't really very smart.

Zswap is quite different, and much more closely matches how more general compressed memory works. Zswap is NOT a compressed swap file on disk. It's a smart "write-behind" caching layer that sits between the pager and the swap device, and it can compress and cache pages that are easily compressible, and plain page out to the actual swap device anything that is not easily compressible, so it never wastes RAM on incompressible data (and also page out with LRU its own cache pages when the cache gets full). It's still not an ideal implementation as it still works through the normal paging system and so it can't pre-emptively go through RAM and compress all the easily compressible pages before they would be considered for paging; and it has more overhead than directly compressed memory, but since Linux doesn't yet have the latter, use zswap.

Apparently ZRAM now has the ability to use a backing disk device too to vastly extend its capacity, but when used as a swap device that just makes it a less effective caching layer with more overhead. Use zswap instead.

https://stackoverflow.com/questions/18437205/difference-between-zram-and-zswap

https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap?
(which if you understand the issues deeply enough basically says that if zswap works for you then use it! The Fedora folks basically have been forced to make some crude compromises to choose zram by default instead of designing something better but are aware that zwap is better if you do it right.)

Note that if your system's primary system storage is on SSD or some other device which similarly suffers from excessive writes, then you really do want to use zswap, but still keep a swap device or file on the SSD; and you really do want to stuff as much physical RAM in your system as you can possibly do/afford to do.

My macOS desktop, with its support in the kernel for compressed virtual memory, has 96GB of RAM, and is still managing to compress quite a large amount of pages from the vast majority of longer-running processes to a current total of about 3GB of compressed data (probably at much more than 4:1, but it's hard to tell). I've seen it as high as 12GB. Because compressed memory works before paging/swapping is considered, it avoids the majority of paging activity entirely. However as macOS apps are often terrible memory pigs, I've still seen as much as 600MB of swap files on this system.

@Greg A. Woods although a lot may have changed in the 9 years that that question was asked? Back then Btrfs was not really an option either.

Fundamentally the concepts have not changed since the SO question -- this is basic system engineering around paging, memory pressure and contention, and the affects of additional software layers vs. algorithm and design choices..

I don't see how BTRFS makes any difference -- sure it claims to be optimized for use on SSDs, but so far as I understand it doesn't really do anything special to deal with wear balancing specifically. Also it would/could only matter if you were using swap files instead of putting swap directly on a block device, and using swap files is really only ever a last-ditch least ideal solution.

The fundamental thing to do for SSDs is to try not to write to them too often in the first place, so when it comes to paging, ideally that's direct memory compression before paging, like macOS does; and second best is zswap; and third best is ZRAM as a plain block device for swap. ZRAM only beats zswap in very specific circumstances where memory consumption patterns are well understood and where any use of any secondary storage for paging is out of the question -- and none of that typically ever applies on a general purpose system like a desktop/laptop or server.

What's good for SSDs w.r.t. to avoiding paging is also typically good for overall system performance, with or without SSDs. Page outs are expensive and if they also lead to page-in requests (which they don't always), then performance suffers, sometimes greatly depending on the level of memory contention.

@Greg A. Woods what I meant about Btrfs was that advice to not use it many years ago is not really relevant today, as Btrfs had been steadily improving, and addressing the issues from way back. So advice on use of Btrfs from back then is really not the same today, and Btrfs support today is now built onto the kernel.

I'm pretty sure too that the actual implementation and stability of Zram would have also improved. Yes the concept may stay the same, but today also be have far more RAM available than 9 years ago, because it's cheaper.

But whilst I am testing it out right now, I'm looking for more recent reviewes and tests around Zram to drill deeper into it.

I should hope Zram and zswap have improved over the years.

However that doesn't change anything about how or why you use them.

We also have far bigger programs to run in that roomier RAM.