Linux 6.2 Lands Support For Multiple Compression Streams With ZRAM

[phoronix]

Phoronix: Linux 6.2 Lands Support For Multiple Compression Streams With ZRAM

Merged last week to Linux 6.2 as part of Andrew Morton's memory management related patches is support within ZRAM for multiple compression streams...

https://www.phoronix.com/news/Linux-6.2-ZRAM-Multi-Compress

[caligula]

Wait what, doesn't this require multiple cores? I thought only poor people with low end hardware use zram. Systems with 8+ gigs of ram and 4+ cores should always buy more ram instead.

[dragonn]

Wait what, doesn't this require multiple cores? I thought only poor people with low end hardware use zram. Systems with 8+ gigs of ram and 4+ cores should always buy more ram instead.

You have absolutely no idea how some people use they computer. I have 24GB RAM, can not put more into it because it is a laptop and do sometimes run out of RAM when doing my job. Fedora as far I remember does ship zram out-of-the-box.

[Veerappan]

Wait what, doesn't this require multiple cores? I thought only poor people with low end hardware use zram. Systems with 8+ gigs of ram and 4+ cores should always buy more ram instead.

I know it was probably sarcasm, but I'll bite anyway.

I've got 32GB of soldered RAM in my work laptop, and there's been plenty of times that it has been on the limit of using it all. My old laptop had 16GB, and zram was essential to me being able to get work done.

Some workloads legitimately require a TON of RAM, and sometimes the memory can't be upgraded, so we need ways to make more effective use of what we have.

[Mitch]

I know it was probably sarcasm, but I'll bite anyway.

I've got 32GB of soldered RAM in my work laptop, and there's been plenty of times that it has been on the limit of using it all. My old laptop had 16GB, and zram was essential to me being able to get work done.

Some workloads legitimately require a TON of RAM, and sometimes the memory can't be upgraded, so we need ways to make more effective use of what we have.

Another use-case to think about with this tool is memory efficiency. Even if your system has 128GB RAM, a lot of times, you want to get the most bang for your buck with that RAM, especially if you have a fleet of nodes configured that way. And it's not like buying more RAM didn't occur to you. Some apps and solutions (e.g. Databases, cache servers, ZFS) are opportunistic and just keep using as much memory as you give them to do things like cache more data than otherwise, so upgrading them all the time isn't the point. It's about upgrading them if they start crashing or slowing down due to low memory.

In these use-cases, ZRam and other swaping solutions aren't a substitute for more RAM any more than an electric motor is designed to replace the gas motor in a hybrid car. The question here is: "why NOT allow this system to swap or compress memory?"

Even if a system never ends up needing ZRam, I can't imagine having it hurts unless you already have another swapping solution turned on or maybe you're doing software development of some sort, and you're trying to keep your products lean and efficient. And you still have visibility into memory pressure vs opportunistic eviction. The CPU cycles at this point would be negligible unless you're seeing a storm, which means you need to upgrade and would've had to anyway if you didn't allow swapping.

[Turbine]

I often exceed 22GB of ram, and have a handful of times used all 32GB. Most modern AAA games use 12-16GB briefly during loading.

[Nozo]

I know it was probably sarcasm, but I'll bite anyway.

I've got 32GB of soldered RAM in my work laptop, and there's been plenty of times that it has been on the limit of using it all. My old laptop had 16GB, and zram was essential to me being able to get work done.

Some workloads legitimately require a TON of RAM, and sometimes the memory can't be upgraded, so we need ways to make more effective use of what we have.

I mean, "unused RAM is wasted RAM" they say.

[_ReD_]

To all the snobs and critics in this thread:
Lets face it: swap is a necessity on linux and everything increasingly comes all-soldered with mostly TLC or QLC storage.
Zram handily saves storage from wear and speeds up page-reclaiming too. Because of this alone, zram extends the life of stuff, while making it snappier in the process! That it can let you stretch ram usage too... Well, that's just a bonus, at this point.
And if you have HDDs alone, then zram or zswap are a total no-brainer. Duh!

On the other hand, on beefier systems it's all even better.
On those systems, having a rather small ram-swap paired with a larger one on fast storage will hit many sweet spots:
(And while for <reasons> I myself am partial to zswap, rest assured zram is no slouch here.)
- it maintains all the aforementioned advantages;
- it leaves plenty of space for precious I/O caches;
- it makes it possible to push RAM hard, whenever necessary.

That's Nirvana... Especially on long-running systems.

[sobrus]

I see some zram users here. If you want to push your machines even further, remember to add a backing device to zram, and writeback all unused pages there using writeback/idle interface. With this, all compressed pages not accessed for a defined time period, will be written out to disk and stop wasting precious memory. Backing device usage (number of reads/writes to hard drive) can be monitored by "cat /sys/block/zram0/bd_stat".

And yes, even with 128GB RAM my system swaps to make room for huge disk cache.

see optional feature/writeback
https://www.kernel.org/doc/html/late...kdev/zram.html

[DavidBrown]

Another use-case for this kind of thing is dedicated systems where you want to run a read-only filesystem. (This is not uncommon in embedded Linux systems - it reduces costs, gives greater predictability of the system, greater security, and power-cycle restoration if something goes wrong. Live USB/CD boots are another such case.) But you might still want your logs and other data while running, and zram gives you a very efficient way to get that.