+1
In the Arch-wiki they linked an article: link
There are so many aspects, I think you will never hit the bulls eye…
And one aspect I am missing totally here: afaik all Arch-based (or systend?) systems use half of the available ram for a ramdisk with /tmp & some more inside to speedup the system, and adjust it at actual demand.
Here, I use my swap-partitions for hibernating, too. So it is no question, how large…
And I think, using a modern nvme (a part of) for a old fashioned swap, it should be fast enough, especially, if you recall the linked article.
Sure, a minimum of real ram, adequate for your working needs cannot be replaced by any swap (compare it to a car…)
Why wouldn’t zswap with a large enough pool size handle reasonably well this situation?
I am starting to feel that there might be some misunderstanding in regard to zswap in this thread:
Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles for potentially reduced swap I/O. This trade-off can also result in a significant performance improvement if reads from the compressed cache are faster than reads from a swap device.
Zswap evicts pages from compressed cache on an LRU basis to the backing swap device when the compressed pool reaches its size limit.
Users with SSDs as swap devices can extend the life of the device by drastically reducing life-shortening writes.
zswap is certainly better than a plain swap file when it comes to performance. But it will not reach zram performance when swap pressure is high because zswap adds latency during disc i/o.
You have shown a picture that you have 15 GB of swap space with zswap. Could you do a test and see how your system behaves if you use 10+ GB of that swap? Please try the stress-ng tool to find out.
My understanding is that unless zswap hits its size limit, only the pages that cannot be compressed will be evicted to disk-based swap device. Now in a real life situation, how could we know beforehand how many percent of the swap pages are non-compressible for us to decide that it will have a significant impact on the system’s performance?
Yes. And I have also said that I am not interested in “provoking” an unreal usecase scenario to artificially fill the zswap with irrelevant “data” to force write operations to the disk-based swap device.
I’m interested in real life, realistic usecases.
My question still remains, in your particular setup with 64GB RAM and 12GB Zram and with your realistic usecase scenario (not provoked stressing), if you have large enough pool for zswap and similar compression algorithm, in order to bring the writing to the disk-based swap device to the minimum, what are the reasons to believe that this would have a significant negative impact on the system’s performance?
We are talking about swap performance. Benchmarking swap space always comes with “writing irrelevant data” to swap.
And with regard to the “unreal usecase scenario” I can only argue: If you have 15 GB of swap space you have prepared your system for large amounts of swapping. Why not testing this setup to see how it really behaves when that amount of swap is used?
Not really. Initially it was meant to be used for hibernation. Something that I am not interested in doing anymore. I just suspend or simply power off nowadays.
I don’t think we can get any further in this discussion. I appreciate your replies even though I never got a clear answer to my question:
On the other hand I have my tests with zram, which indicate that it is 10 and more times faster than normal swapping bringing my PC from a stand still during normal swapping to normal operation speed with zram.
I conclude, without any personal experience with zswap, that zram is faster than zswap.
Well, if without any personal experience and without providing any data as to how much faster, in what scenario, with what configuration etc., you arrive at this conclusion, I have nothing more to add.
I conclude: I think I have a reasonable (to me) standing on this matter that there is no unequivocal, conclusive conclusion, universally valid for every user, every hardware, every configuration, every use case when it comes to zram and zswap. It all depends
I don’t think this is likely to cause a material issue. The amount of CPU overhead by this compression is pretty low. If your CPU performance degrades to the point where this would be an issue, you are going to have bigger issues.
In that scenario, where you have sufficient available memory, it won’t make much difference if you use zram or zswap. The comparison is only interesting when you are under pressure. For that matter, even a traditional swap partition would work fine.
If you aren’t memory constrained, just go with whichever one you are more comfortable.
The thing about swap is that it is totally use case dependent. We all have different use cases and realistically each user needs to test and evaluate what works for them.
I don’t really think there is any single “best” option or a magic table that can tell you what to to do.
Sure, this was never in question. It is always good to have options. I was just sharing my 2 cents.
You asked me multiple times about proof regarding the zswap/zram performance. I gave it to you with links. You even gave it to yourself with the link you shared in your first post. Thats it.
@wolfn you are right, almost all of the distros these days mount /run and other partitions in RAM. They typically reserve 10% or 2GB of RAM for this. In addition if /tmp is also mounted as tmpfs then it will also consume RAM. So reduce SWAP pressure and disk writes, we need RAM. But RAM is already provisioned for many things.
What surprised me was when @mbod clarified that Fedora was using ZRAM equal to physical RAM and that too Out-of-the-box. I might be one of the very few distros that do this.
stress-ng is part of which package? It is not installed in my EOS system.
Also is there any other package apart from stress-ng that ca be used?
I was under the impression that zswap compresses and hold the swap-able pages in RAM and not in disk/Swap partition/Swap file. It does not write the disk at all, unless the memory page is not cant be compressed. Is that not the case?
Disk in this case would be NVMe or SATA disk or Flash memory.
Thanks for clarifying that. I am a big fan of Dell Laptops and after 8+ years Dell throttles all of its laptops to 1.5GHz or below. Irrespective whether the laptop is connected to power or is running on battery. I was coming from that angle.
Yes, that surprised me too when I tried Fedora on my laptop. This is even going so far that Fedora laptops can not hibernate because they have no persistent swap.
In order to enable hibernation Fedora users can follow a rather complex tutorial to enable hibernation in conjunction with zram. I followed these instructions and can confirm that it works well. Nevertheless, I find this a rather user unfriendly approach for laptop users.
Here are the hibernation instructions. They might be helpful for any zram user who wants to enable hibernation:
And here is some more interesting info about zram from the Fedora Project:
