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.