zram can be a life safer for older machines. Mine has only 2 GB, and on other distros it made a huge difference in general responsiveness.
it is swapping on a ram disk wich is comprimized so if the ram gets low, it dont have to get written on the slow hdd/ssd.
this need more cpu but is even faster than swapping on the harddrive.
Please take a look at this thread: https://solus-project.com/forums/viewtopic.php?f=14&t=1864
It's also a life saver for those with cheap/old SSDs or eMMCs (my case), which must reduce the amount of writes to disk as much as possible to keep it working long enough (can't replace when it's soldered). With 2 GB of RAM, swap is heavily used at least once a day. This wouldn't happen back when I had
zram-config
activated in Ubuntu. zram-config sets everything up automatically.
Many games on Solus are unplayable without zRAM on machines with little amount of RAM (computer literally hangs).
I don't want to move back to Arch, please consider adding this soon :(
Side question, is enabling zRAM currently truly impossible (because of kernel configs) or just no one has figured out how to enable it yet?
It's not impossible. I've repeatedly asked people for benchmarks to demonstrate it actually improves things without regressions.
It's been asked for a few times, and I've asked the same thing each time. I've also said it's unacceptable to expect users to manually
run scripts to make it work, it must work out of the box for all if they need it.
It's hard to provide Solus-accurate benchmarks considering it's really hard for an average user to get it to work right now (no zram module in /lib/modules/(version)/kernel/drivers at all).
I've been able to find this kinda old thing though. I don't know whether zRAM is a thing that should be enabled for everyone, but it really is a life-saver for low memory PCs, because it only sacrifices a bit of CPU power.
Wouldn't it be a better option to, at least just for now:
zRAM cound be later, when it's finally solved whether it's worth it or not, included as an option in the system settings, maybe enabled by default if 2GB or less RAM is detected.
I agree that it's unacceptable to expect users to manually run scripts and stuff, but it is worse when even that's not an option.
I have a netbook with 2 GB of RAM. It's enough for simple tasks, but when you run a game that is compatible with your processing power but it needs a little more RAM (something like 200 MB more and you don't have it), ZRAM helps. It keeps the game from reaching swap (confirmed by running swapon -s while it's running); consequently, it does not slow down. That is on a lighter DE. If I decide to run Unity, only ZRAM will make it usable. Doesn't make miracles, but gets close enough.
@ikey would love to do some performance testing on Solus, but how can I?
Phoronix did some performance testing ages ago (http://www.phoronix.com/scan.php?page=news_item&px=MTM1NjQ) on Ubuntu.
ZRAM appeares to be used by Google on Chromebooks and Android, and reportedly makes sense on RAM limited devices.
I would like to give it a try on my netbook to see what happens.
From what I understand it's in the linux kernel for a few years, but not available in Solus. Isn't there a way to enable this module as a user?
I would love to see this too as I just bought a new laptop that has a low amount of RAM.
Oh boy, this really sucks...
Already years of topic, no explanations and we don't even have zram module distributed with mainline kernel for us to manually set things up. Also, I found out now that I can't just "zcat /proc/config.gz". Why?
EDIT:
Ok, just found out that it (the lack of /proc/config.gz) was actually lack of some modprobe stuff but come on...
So people are asking for metrics. I'll look on how could I set up environment to build a custom kernel with Solus (and on top of Solus mainline's template/kernel).
Already years of topic, no explanations and we don't even have zram module distributed with mainline kernel for us to manually set things up. Also, I found out now that I can't just "zcat /proc/config.gz". Why?
There is no reason for us to ship a module for something we aren't supporting. Yes, after years we are still expecting metrics. That is how we (Core Team) are able to make an informed, educated decision based on technical merits. If someone wants a specific feature, it is on them to provide sufficient information to justify its enablement.
Enabled by default in fedora replacing swap partitions AFAICT. https://fedoraproject.org/wiki/Changes/SwapOnZRAM
"zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never touches swap, this overhead is the sole cost. In practice when not used at all, feature owner has experienced ~0.04% overhead."
I did a test with our system embree (v1.13.0) compiling it with gcc in which it uses about 24Gigs peak. My system has 16Gigs of memory.
zram (8GiB, lzo-rle)
real 6m50.328s
user 73m4.116s
sys 3m44.517s
swapfile (10GiB)
real 10m42.266s
user 62m25.999s
sys 2m39.408s
Compiling with zram was ~35% faster. ccache was disabled and the disk was freshly fstrim'd before each compile. Only the compile itself was timed.
After compiling zram still had 282.1MiB in memory compressed to 85.4MiB
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 8G 282.1M 85.4M 121.8M 16 [SWAP]
On systems with little memory and storage such as Chromebooks zram makes a lot of sense. I used to use a chromebook with 2GBs of memory and 30GB of storage. On such a system even just opening 6 tabs in a browser could cause it to swap. Zram on such a system was a lot more responsive to use. Setting aside 4Gigs for swap on such a system was a big ask.
I set the following options in linux-current to enable zram.
+CONFIG_ZRAM=m +CONFIG_ZRAM_DEF_COMP_LZORLE=y +# CONFIG_ZRAM_DEF_COMP_ZSTD is not set +# CONFIG_ZRAM_DEF_COMP_LZ4 is not set +# CONFIG_ZRAM_DEF_COMP_LZO is not set +# CONFIG_ZRAM_DEF_COMP_LZ4HC is not set +# CONFIG_ZRAM_DEF_COMP_842 is not set +CONFIG_ZRAM_DEF_COMP="lzo-rle" +CONFIG_ZRAM_WRITEBACK=y +# CONFIG_ZRAM_MEMORY_TRACKING is not set +CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 +CONFIG_BLK_DEV_CRYPTOLOOP=m +CONFIG_ZSMALLOC=(y/m) ? +# CONFIG_ZSMALLOC_STAT is not set
IMO, zram should be enabled as a module at the very least. The peeps that need zram the most have systems that cannot easily compile a kernel to provide comparisons.
Additionally, something like zram-generator packaged to allow easy configuration would be a nice to have as well.
With that being said I would like to try and verify the 0.01/0.04% overhead claim from Fedora.
Did some additional testing. I used zram-perf to bench zram modifying as required and then modified it again to bench a swapfile on a sata ssd.
This is close to a worse case scenario, single stream and fills the entire swap (but highly compressible). However, not too surprising. We know memory is significantly faster than storage. What is most interesting is the insight into cpu utilization. At first glance the additional cpu utilization required for compression doesn't seem too bad.
# ./swapfile-perf size of file '/swapfile' = 8589934592 read: 147.084MB/s write: 115.348MB/s
# ./zram-perf size of file '/dev/zram0' = 8589934592 read: 4027.53MB/s write: 533.455MB/s
I'd like to find a better way/program to graph cpu utilization then re-run on some older systems. I have a sandy bridge 2c/4t as well as a haswell 2c/2t I can run it on next. CPU utilization may look quite different on those systems.
There is no reason for us to ship a module for something we aren't supporting. Yes, after years we are still expecting metrics.
Hi, metrics are available and zram is used by many projects / distributions with good feedback. I think it's not needed to enable it by default, a first step should to have the module compile in the kernel. And let people activate it if needed. The tooling can be added later and is required currently. Compiling a custom kernel just to have zram sounds unfair in many cases.
In my case I have high memory usage for a current project, I don't really care to loose a few CPU cycles, but I need to avoid swapping (who kill way more CPU cycles than using zram).
After some experiment I have a working kernel based on linux-current that work correctly and setup of zram with zramd + systemd (https://github.com/maximumadmin/zramd/releases), with some guidance, I'm open to create a solus package for zramd, and a patch for the linux-current.
After a full day of work with my current project that require lots of RAM (I have 16Go), I can confirm that zram can help even with big amount of RAM. Before ZRAM, I have multiple freeze per day and sometimes even needs a hard reboot to "unfreeze".