Meta Developing Compressed RAM 'CRAM' For Linux: Better Than ZRAM and Zswap? (phoronix.com)
- Reference: 0186090894
- News link: https://hardware.slashdot.org/story/26/10/10/0631257/meta-developing-compressed-ram-cram-for-linux-better-than-zram-and-zswap
- Source link: https://www.phoronix.com/news/Linux-CRAM-Compressed-RAM
> With today's memory shortages, high prices, and ever increasing memory capacity needs, Meta engineers have been working on Compressed RAM ("CRAM") for Linux.
>
> This hardware-offloaded compression still allows cacheline/byte access to compressed memory and in turn a better implementation than the likes of ZRAM and Zswap. Very promising is that there is near-native performance to raw DRAM speeds with CRAM... For end-users that may already be relying on the likes of Zswap or ZRAM, CRAM is offering near-native DRAM speeds. Read-only data is shown to be as fast as the raw DRAM performance. And for memory writes, CRAM is much faster than ZRAM or Zswap or plain swap.
"Most of the individual pieces needed to support CRAM are already mainline," the article points out. [3] Tom's Hardware writes that "It uses a private NUMA node (essentially, a ghost CPU) instead of pretending to be a block device, and this lets Linux continue using all of its memory semantics, including migration and ballooning, to manage CRAM."
> Because CRAM is stored in RAM and treated as RAM, with full cacheline/byte access, it can be accessed in a read-only fashion with little delay; just the cost of hardware-offloaded compression... Even when you enable writes, CRAM is still much faster than ZRAM; 5.4x in the worst tested case of 20% writes. That's a huge drop from the 452x read-only case, but keep your context; a 5.4x speedup is still titanic. The massive performance cliff when writes are involved comes down to the need to page fault and migrate folios back to the original NUMA domain, as you can't write directly to compressed data; you'd corrupt everything...
>
> While the obvious target of the work here (given its origin at Meta Platforms) is big Linux servers, ZRAM and Zswap are used all over the Linux ecosystem, even on machines as constrained as the Steam Deck. Many distributions enable one or the other by default. CRAM seems like it could offer a considerable speed-up for some of these machines, so hopefully it finds its way into the kernel once the remaining implementation questions are answered.
[1] https://www.phoronix.com/news/Linux-CRAM-Compressed-RAM
[2] https://lpc.events/event/20/contributions/2424/
[3] https://www.tomshardware.com/software/linux/new-linux-tech-compresses-memory-in-ram-as-ram-for-452x-speedup-new-cram-method-offers-giant-boost-to-compressed-memory-reads
data || GTFO (Score:3)
> it can be accessed in a read-only fashion with little delay; just the cost of hardware-offloaded compression..
This reminds me of the days when we were using hardware RAID controllers...even though it was all done in hardware, it seems like they were somehow always slower than the Linux software RAID controller. I never figured out why. What I am saying is, I don't trust the hardware-offloaded compression to be faster without seeing the data.
Re: (Score:2)
It reminds me the days I needed DoubleSpace to fit DOOM on my 20 Mb hard drive (or whatever it was).
Re: (Score:2)
> it seems like they were somehow always slower than the Linux software RAID controller.
That's your confirmation bias. Back in the day people specifically used hardware RAID precisely because it was faster, measurably so. Also I/O performance wasn't the only metric. Software RAID consumed considerable CPU resources back when we weren't running threadrippers with half their cores idle. Not only was I/O performance better on hardware RAID but your CPU utilisation was lower allowing for more cycles to be dedicated to the application (quite critical for database servers of old).
Re: (Score:2)
Nah dude, you're a Windows programmer. I am fully in concordance that hardware RAID controllers were faster on Windows. Microsoft probably made a deal with RAID hardware manufacturers to keep their software controller slow. That's the Microsoft way.
But on Linux? The software RAID controller was faster. The job is I/O bound, not CPU bound.
Re: (Score:2)
In server-grade hardware, sure. And you paid $$$$$ for it.
The earliest "consumer" grade RAID cards, by contrast, were basically just softRAIDs with a built-in IDE controller - And that's still true to a large degree; the "RAID-mode" in your gaming PC's BIOS is still merely offloading the hard work to the CPU.
I'm not claiming Linux' softRAID implementation was or wasn't faster than cheap RAID hardware, but I have no problem believing it could at least be comparable.
Re: (Score:2)
So, at first when they were introduced they were faster, because they used cores comparable to your CPU. That's why they were expensive. Then cheaper ones were introduced, they did less of the work, they were slower. In that case more of the "RAID" magic is happening in the driver instead of on the card. But expensive RAID controllers with full offloading were still fast. Eventually our CPUs got to be fast, and now software RAID is usually faster.
In the case of hwraid vs swraid, there is another reason not
turns out you can (Score:1)
download more ram.
The return of Ram-Doubler (Score:3)
Back in MacOS 8 days or thereabouts.
It didn't have the benefits of hardware compression though.
Re: The return of Ram-Doubler (Score:2)
Here's a fun read about SoftRAM 95, a product that tried to do the same for Windows. Like many products, they shipped before it was complete. As in, they forgot the actual compression.
Re: The return of Ram-Doubler (Score:2)
Sorry, forgot the link. [1]https://devblogs.microsoft.com... [microsoft.com]
[1] https://devblogs.microsoft.com/oldnewthing/20211111-00/?p=105897/
We also need better programmng (Score:2)
Better programming means fewer computing resources for the same task, RAM included.
C or Rust to the rescue
Re: (Score:2)
C is pretty good at that, but I haven't seen statistics for Rust. I suppose all the complex stuff could be optimized away during compilation, but I don't know that it is.
Re: (Score:2)
Too many layers of abstraction. You're running an OS inside a slice of a processor in a virtual machine. Inside that sits more containers like docker and even python now with virtual envs. Every layer ads more cpu instructions to simple tasks.
Re: (Score:3)
Better programming means better programmers. We are currently going the other way with bad programmers being replaced by even worse slop.
Re: (Score:2)
Sure, the rest of the market is barely keeping pace (4%) with inflation (3.4%) YTD; but but but, NVidia is shiny and AI is going to save us all! Pay no attention to the billionaires promising us a post-scarcity world while building massive survival bunkers in the background.
Re: (Score:2)
The [1]FOMC [wikipedia.org] has been [2]manipulating [federalreserve.gov] the traditional (stock, bond, commodity) markets to prevent market crashes (especially since 2008). The side effect is that it's become more difficult to get the large returns from market swings (ie crashes and rebounds). So now speculators (let's not call them investors) are searching outside the traditional markets for "big profits".
RAM is simply the latest victim.
[1] https://en.wikipedia.org/wiki/Federal_Open_Market_Committee
[2] https://www.federalreserve.gov/monetarypolicy/fomc.htm
That old idea again (Score:2)
It seems enough time has passed since the last catastrophic failures in this space that people do not remember. No, this does not work except in some very specific scenarios. What Meta is probably doing is get hardware done for their very special and very irrelevant elsewhere use-case. That does not even merit a story.
Re: (Score:2)
I'd be interested to see the power budget on this. Regular RAM's power cost mostly scales with installed capacity, compressed RAM's power cost is going to scale with usage. It might be a big win for specific applications that need to have huge amounts of fast memory on-hand but aren't hammering it constantly. Doesn't look like Meta published any power figures.
If the compression power cost is low enough, it might be a win for everyone. Otherwise, it's still a win for the hyperscalers: they get to exchang
Re: (Score:2)
Right, both of you.
If you compress a harddrive or stuff a RAR file full at max compression, it costs power (CPU cycles which adds up to more electrical power) to access that data at a slower throughput VS just accessing the data pre-compression.
Haven't read the whole article, but I bet their aiming for t he compression processor on the RAM stick, along with the ECC chip... so any request for data runs through (and is slightly slowed by) ECC, then to the compression processor (which, I assume, maintains a ta
Think smaller (Score:2)
> ZRAM and Zswap are used all over the Linux ecosystem, even on machines as constrained as the Steam Deck
The technique is especially useful on even more constrained systems, like embedded controllers in 3d printers and such. The only places I've ever needed ZRAM were on a phone with 512MB and on my 3d printer with 256MB.
Re: (Score:1)
Seems like that would be entirely false. Embedded and constrained systems are where a proper amount of RAM is easiest to provide directly. Your perspective is after the fact, you apparently desire to use systems beyond their design points. More flexible memory would be most advantageous in programmable systems, not fixed function ones.
How does one know where they "need ZRAM" and where they don't?
Re: (Score:3)
> you apparently desire to use systems beyond their design points
Everyone wants to use systems beyond their design points. Or rather, more accurately, the design point is *always* the cheapest way to accomplish a goal, and that's a moving target.
If you are a company that provides an embedded system with a known functionality that requires a specific amount of RAM, and you realize you can ship that system with less RAM because you of CRAM or ZRAM, you just decreased your costs and increased your margin. There is literally no embedded provider that wouldn't be looking at t
Re: (Score:2)
You're thinking of what amount to ultra-SFF PCs. In the truly embedded space, having a fixed (and usually tiny) amount of RAM on-die is the norm rather than the exception.
That said, Meta clearly isn't targeting 68HC05s here, so the distinction is largely meaningless.
Re: (Score:2)
> Seems like that would be entirely false.
Sure, if you have no experience and want to share your feelings about it.
> Embedded and constrained systems are where a proper amount of RAM is easiest to provide directly.
This is a matter of perspective. Where you're shipping many units and want to save money, it can easily be false, as it was in both of my examples.
> How does one know where they "need ZRAM" and where they don't?
man free