I suggest you have both zram and your disk swap file configured.
Zram will handle small paging needs and the disk will only get used once zram is full.
Well, I’d be curious to read more of the details of the actual architecture, design, and implementation, including compression algorithms in use by various Linux distros.
There is a performance cost (overhead) to doing compression. I wonder what is the true gain versus just using the RAM allocated for paging as RAM.
And I’d love to see real performance data on the cost of using zram as paging:
- increased amount of paging as a result of less RAM available to be used as RAM
- performance hit of doing the compression
There are so many other factors related to designing memory management:
- working set size per process or thread
- paging algorithm used (including the pre-fetch policy)
- profile of running processes and threads with respect to memory access patterns
All these factors and more can vastly increase system performance. I would venture to guess that a configuration that considers all of these factors would not suffer at all by using hard disk for paging.
By the way, this paper was an interesting read (LZO sacrifices compression ratio in favor of speed):
https://www.researchgate.net/publication/261486408_Compression_Speed_Enhancements_to_LZO_for_Multi-core_Systems
At this point, I’m just curious to learn more about the details. Of course, this is not important with respect to my original problem, which all of the respondents here helped me solve.
I found this page today and started reading:
https://www.kernel.org/doc/html/latest/admin-guide/mm/index.html
Thanks again to all…
No ram is reserved for zram, only when paging is needed is ram used (about 10kiB is the overhead to set it up).
The performance of compression has to be compared to the time needed to do I/O, which is huge even on SSD.
Given you cannot add ram then zram is the best technical solution.
Given you cannot add ram then zram is the best technical solution.
Well, I guess that makes sense. If one cannot add RAM, I suppose a little bit of gain in virtual memory is better than nothing.
But that is the only advantage that I can see. And it still seems like a stop gap measure.
I’m wondering how to interpret the ‘USED’ column of the “swapon -s” and “swapon --show” output.
$ swapon -s
Filename Type Size Used Priority
/dev/zram0 partition 8388604 679536 100
/dev/sda4 partition 134765564 0 -2
$
$ swapon --show
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 663.6M 100
/dev/sda4 partition 128.5G 0B -2
$
Should I interpret the output to mean that 663.6 MB are actually in use, that is, that space is being used to hold pages of RAM that have been pages out of RAM?
The documentation suggests using zramctl
to get a better readout of the compressed and uncompressed sizes.
https://fedoraproject.org/wiki/Changes/SwapOnZRAM
Example: A system has 16 GiB RAM. The proposed defaults suggest the /dev/zram0 device will be 4 GiB. If the workload completely fills up swap with 4 GiB of anonymous pages, what’s happened? The zramctl command will display the true compression ratio. If 2:1 is really obtained, it means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the actual RAM usage, and is also the net effective eviction. i.e. 4 GiB anonymous pages are evicted, but are then compressed and pinned into 2 GiB RAM, for a net memory savings of 2 GiB.
Thanks, @glb I’ll read that page you referenced first.