RAM is getting expensive, so squeeze the most from it Linux has two ways to do memory compression – zram and zswap – but you rarely hear about the second. The Register compares and contrasts them. The Linux kernel's zram tool has been in the news this week. Phoronix reports that the new patch could make some zram operations 50 percent faster. Thanks to the increasingly desperate …
With my P1 90Mhz 16MB RAM and WfW 3.1 I "discovered" that, I if I made a 4 or 8 MB RAMdisk, compressed it with doublespace and pointed /tmp, /temp and the windows pagefile to it, the machine was greatly accelerated (especialy compile jobs) AND coyld fit bigger software than woulkd be possible otherwise.
Sadly, win95 put an end to it, as the swap bypased the doublespace via APIs and stored everything uncomprerssed.
One of the reasons I delayed the upgrade as much as feasible.
Coming from an IBM mainframe background you used dedicated Page disks (real huge spinning rust) normally, and dedicated Swap disks only when you were right in the sh**.
I was told stories of a British electrical/electronics retailer (which still exists) that was so tight they used to create Page and Swap datasets (files) all over data disks. With entirely predictable results. There were tales of their entire online system stopping when the OS swapped, leaving store terminals hung until it sorted itself out.
When I got a home PC one of the first things I did was fit a second hard drive, a cheap secondhand one, as a Page disk. The difference in performance was noticeable. Since then I've carried on doing it on my Linux PCs, until SSDs started arriving. I even used USB sticks for page/swap.
Looks like its time to start doing it again!
We could just work out who has two sticks of RAM, sneak in during the night and take one stick. Leave one in.
It's a victimless crime...probably.
Back in the mid 1990s, a software package called Stacker implemented disk compression for DOS and Windows computers, which was considered an innovation at the time. Although the vendor claimed it would double disk size, most users routinely saw a 50% increase in usable space, which is still nothing to sneeze at.
Unscrupulous PC vendors started installing it an selling systems with 200MB hard drives claiming that they were 300MB, because they pre-installed Stacker. Of course, OS/2 users discovered that the advertised "300MB" hard drive was actually 200MB, and took the vendors to small claims court.
Today, some vendors are using the same "victimless crime" argument. There are vendors selling PCs with "1TB of storage space" that have a 128GB SSD and a one year Microsoft 365 subscription that includes 1TB of online storage.
Never underestimate the sleaziness of PC vendors.
Old people, with old computers, with old RAM ... Single Inline Memory Modules using Fast Page Mode RAM or Extended Data Out RAM, will not make useful RAM theft targets. Likewise people with REALLY old PCs, with individual RAM chips installed into individual RAM sockets.
Techs at computer store I worked in back then called the process of installing those chips onto the motherboards "RAMming up" a mobo.
Now get off my lawn.
On a related note, Connectix made a software called RAM Doubler back around the Win 3.11-95 era that actually worked, unlike many dubious products at the time which made similar claims.
There's a nice writeup about it here: https://computeradsfromthepast.substack.com/p/connectix-ram-doubler
Because, historically speaking, programmers don't give a flying fuck about the amount of RAM their code uses.
This trend started when Windows 95 came out and RAM was a dime a megabyte.
The only way Redmond programmers are going to pay attention to their RAM usage is if their office gets as small as their RAM usage gets large.
>> programmers don't give a flying fuck about the amount of RAM their code uses.
I am not sure that is correct. It didn't use to be that way. It also doesn't explain why Linux has to copy that methodology.
I remember running a Linux desktop on 32MB of RAM. It didn't have the bells and whistles which seem necessary these days. My productivity on the command line has not increased with the amount of RAM I have installed.
I think the point is that things have not necessarily got better, despite the bloat. Bloat seems to me to be correlated with the addition of frills; everything from 24 bit icons and buttons to loaded-by-default weather apps, slideshow desktop backgrounds, grammar checkers which suggest "I" when "me" is grammatically correct to adverts popping up in the "start" menu.
As I've mentioned previously, I once made WfW3.11 (with Novell networking) and office (Word 6) work perfectly well, printing and all, on a 386SX with 20MB HDD and 2MB RAM. Yes it was more comfortable on that secretary's boss's 486/100MB/4MB, but he "needed" the faster computer, never quite worked out why.
And I would still contend that one of the best (most usable day-to-day) bits of software I've ever owned was Computer Concepts Impression, something they termed a "document processor". It had DTP functions in software which was a highly competent word pocessor too.
It was possible to install it, with a selection of fonts and such, on a single 1.6MB floppy disc and run it on a 1MB Acorn Archimedes with no hard drive (though remembering that the bulk of the OS and utilities were on ROM).
I like LibreOffice, don't get me wrong, and I tolerate Word, but I miss Impression, and Acorn Draw, for which there is no equivalent in Office.
It would be interesting to see a stripped-down version of Word. Find out how much of the bulk is actually core functionality.
M.
"It would be interesting to see a stripped-down version of Word"
Not only for reduced RAM (hopefully) but also a segregated fubnctionality with Office 364, MS could do well to bring back MS Works. It had more than enough funtionality for 80-90% of users. They could then leave Office 363 as a power-users / professional suite
"I remember running a Linux desktop on 32MB of RAM."
My wife has a very modest laptop with a Celeron and 4GB of RAM running Mint 22.3 without anything fancy on it. With Thunderbird, Firefox and two small LibreOffice Write documents open, her laptop slows down to a crawl, because more than a gig of core is being swapped out already at that point. (She'll be getting another DIMM installed next week before I have to dodge a flying laptop.)
"This trend started when Windows 95 came out"
No, it started with Windows 3.1x applications.
I ran a FIDOnet BBS at the time, and the data volumes in the file distribution portions of the network suddenly exploded. Regular .ZIP file sizes were on the order of 50kb or so, but Windows apps were easily a factor 10 larger (400-500k was common). Mind you, this was in the days when 14k4 dialup modems were the standard and only rich sysops could afford something faster, which only worked if the other guy had a faster modem, too.
With nightly file transfer times (and phone bills) and exploding tenfold like that, it took all the fun out of BBS'ing. Not to mention harddisks filling up far too quickly. Plus, with all modems being engaged so much longer due to the larger data volumes, FIDO nodes became progressively harder to reach. It was a pain, so I remember it well.
Since memory usage was (and is) a factor of the executable code size and Windows 3.x apps linked in everything including the kitchen sink, Windoze required much more RAM than DOS applications did, even then.
> Word has one file open - 750MB.
I can only tell you that Word 97 still works, you can activate it with the magic number 1111-1111111, and its file format remained constant for the next decade so everything can open it. I think I reviewed it when it came out and mocked its size, but now, it can run inside any vaguely recent processor's L2 cache.
Runs a treat in WINE, including installing all the Service Releases, and is blazingly fast on an old low-end Core i5.
Outside the business and official users — such as community clubs etc Word97 .doc format is still the lngua franca for document exchange.
One might shudder at all those Windows 9X and XP PCs out there running Office97. Reality has a nasty habit of knocking the shit out of illusions.
Actually there are a lot of Openoffice/Libreoffice installed by relatives, neighbours etc, on somewhat more recent PCs with the strict instrucion to always save in "office 97-2000" format with the user often unaware that it is not MS slop.
Her indoors had both LibreOffice (first) and Office2019 (later) on her Win7 PC but the default remained LO until an update of something "fixed" that. A frantic frantic phone call about how something had completely broken MS Office and she could do anything thing - after more than a few (cross) words I worked out that she hadn't ever seen Office2019 and told her to click on the LibreOffice icon and find her documents from "recent."
Uninstalled Office2019 on the next visit as clearly MS had "broken" it. So I had the install media and two licences for 2019 with zero likelihood of their ever being used.
For almost all such users Wordpad or MS Works would have been more than adequate.
My primary "desktop" is a Lenovo P15 workstation laptop from 2022 with a 8 core Xeon and 128G of ECC ram. No swap, usually 100G of ram available. Didn't really need more than 32 to 48GG, just wanted to max it out at the time wasn't too expensive in early 2023. I expect this to last me till 2030.
Laptop before that was a Lenovo P50 which I got in 2016. I specifically recall the kernel being terrible with swap at the time because it came with 16G of ram, and it would grind to a halt for a minute or more doing basic stuff because of swap. I ran the same workload (just newer OS/kernel) as my previous Toshiba Tecra A11 from 2011 which maxed out at 8G. The 16G laptop had plenty of ram but still swapped at times like crazy, so much the mouse cursor would stall and the system would freeze for many seconds at a time. "Swapiness" settings did nothing. A co worker said he had seen similar issues with Linux for years. I had not till that point.
16G ran worse than 8G just with a newer kernel/software. So crazy. I quickly had to upgrade to 32G which fixed it. Later upgraded again to 48G for no reason.(Max is 64G for that P15)
All 3 laptops are on my desk still with their lids closed stacked neatly on shelves with dedicated laptop coolers below each one.
later ran into linux slab memory leaks(resulting in swapping) at work on Ubuntu 20 which I spent about a year in investigating, that was super annoying, onky fix is to reboot. Newer kernels helped a bit and it seems maybe totally resolved in Ubuntu 24.
Not exactly related to the compression discussion, but is for the RAM savings one :)
I've got an ancient HP Z800 circa 2011, with an SSD, an NVMe (I always call these "ENVY ME!" drives, is that right?) plugged into the PCIe slot on a card, 100GB of blazing 1333MHz DDR3 and dual X5675 CPU's.
It cost me 90 dollars 5 years ago, which translates into less than 8GB of DDR4/5 RAM today I think.
I originally bought it to run Proxmox, but will run just about anything I toss at it.
It can even run modest LLM's (under Ollama) on just the CPU's, though somewhat slowly...saving up for an RTX3060 for it to help with that.
The power supplies are the greatest weakness, once it dies you toss the computer generally, so mine sips, or maybe gulps, filtered power.
>The power supplies are the greatest weakness, once it dies you toss the computer generally, so mine sips, or maybe gulps, filtered power
Won't help. The PSUs in the z800 had an abnormal high failure rate, and filtered power doesn't change that. However, for someone versed in electronics the PSUs are easily repairable (and if they use higher spec parts they will also last much longer than a new one would have).
The successor z820 uses a revised version which sadly is incompatible with the z800. These PSUs are robust so HP used the same ones in the z840 as well.
Same here. Sitting on a z8 G4 with 384GB RAM which should be enough for a while, and on the other desk there's a Dell 7820 with the same amount of memory.
Considered moving to a newer system but the current memory prices just make this completely unrealistic, especially with DDR5 now reaching price parity with brand new Chelsea tractors.
"So you can have some zram as well as a swap file, and it will move the least recently used stuff from zram into disk swap as needed."
I was looking at these recently, and have been unable to find out if data remains compressed when zram moves data to the disk swap. I feel that if it did, then this would be a feature worth telling people about. My understanding of the architecture of the swap system is that if the zram swap device fills up, then the existing data will remain there, and new data swapped out of memory will go (uncompressed) to the disk swap. If data were to be moved out of zram swap to disk swap, it would be de-compressed as it leaves zram.
Zswap does write compressed data to the backing swap disk, so reducing the amount of writes, which is good for ssd's.
It appears to me that zram is only good if you have no disk swap, and zswap is the better option if you do.
I always encrypt swap partition, because raw memory contents may be sat there in the open.
> have been unable to find out if data remains compressed when zram moves data to the disk swap.
I thought it did, but during my research for this article it looks like no, it doesn't. I _think_ it's expanded again so that the existing unmodified read/write mechanisms still work.
For a previous recent piece, I found that the RAM image dumpted into the swap volume for hibernation _is_ compressed. So there is a different code path that can read/write compressed data.
Some unification work here is needed, I reckon.
I think I saw something on Phoronix a few months ago that migrating compressed pages to swap while keeping compression was work in progress. Apparently not as straightforward as first appears.
Given block devices have a read/write granularity of a "block" there wouldn't be much point in writing a 4K page compressed to 1K to a 4K disk block so I suppose it needs another layer between zram and the disk swap to manage multiplexing compressed pages into disk blocks efficiently.
Personally I use zram just to reduce write traffic to the SSD swap partition but not really a problem in my case.
You mean to surf the web right?
This 8GB advice has never been so poor and ironically it is extremely poor for anyone who pays attention to swap. For over 20 years software for CAD, 3D, 2D, NLE, profiling, etc. hasn't worked dependably with 8GB swap and anyone who uses these knows this every time the GUI freezes/seizes. Now that's just typical GUI based userland software but it's the same with software services. Anyone running a modest DB laughs at 8GB swap. Any VPS user knows that a modest GIT repo wants at least 16GB. A modest mail daemon minus the DB will eat 8GB swap with queue.
For the audience of this article, again the people who pay attention to swap, there is simply near 0 use cases where 8GB swap will be acceptable.
> software for CAD, 3D, 2D, NLE, profiling, etc.
Nothing like which I ever use, myself. This may be why I can still get productive work done with my T420 and W520, which are now 15 year old laptops. They run VMs with aplomb, while I have 2 browsers, a multi-protocol chat program, a music player, and my horrifically bloated distraction-free writing tool of choice all open. And a music player, typically. They can handle 2 full-size modern 64-bit OSes in VMs concurrently at a push. I have successfully bootstrapped an entire working K8s cluster on a single 8GB PC before now.
So, no, not just to surf the web, no.
But those are cautious conservative low-end numbers. If you have the room and don't mind, then sure, you could allocate a tonne of swap. What do you in fact recommend? Since you don't specify.
2x RAM like of old?
Generically, $RAM + $BIGGEST_PROCESS == $SWAP_SIZE
In short, I generically use the sum of the largest process the machine will handle plus the physical RAM quantity. My rationale behind that is that the machine has already ate all of its own RAM so the job is forced to swap which has caused a processing slow down too great to be overcome (losing race condition). If I'm desperate,, like with a cheap VPS, I'll set it to the size of the largest dataset. No matter what, knowing what software will be used should be considered, at least a little.
Once you hit swap it's no longer a RAM problem, it's a permanent storage + unknown data quantity problem. I've never been sure where the "RAM * X = ENOUGH" formula came from (maybe a swap file had to be a multiple/denominator of RAM way back when?). Does it matter how much RAM you _HAD_ when it's now become about how much filesystem you need,?
2xRAM never applied to Linux (nor Solaris 2); it's an old BSD (hence SunOS 4) thing where if you had nMB of RAM then you needed nMB of swap as backing store, so 2nMB swap resulted in a total of 2nMB of virtual memory (if swap was smaller than RAM then you couldn't even use all your RAM). Yuck.
So to match the old SunOS rule-of-thumb of "swap = twice RAM" then you'd have "swap = RAM" to get the same effective result. But that's from back when memory was small; 4Mb of RAM was luxury. Now we have gigs of RAM; do we really want to be doing slow slow slow swapping of gigs to disk?
It gets even more complicated. Old school swapping doesn't really happen these days; it's pretty much all paging ("swapping" used to mean placing a whole process into swap; "paging" works at a memory page level). Paging is more effective because it means a program could still be running and doesn't need to page back in the swapped out pages if it never touches them. Note, though, that we still call it "swapping in/out pages of memory" so the terminology is less than clear :-) But this means that really infrequently used pages of memory can be thrown away from memory and placed into swap with pretty much zero performance impact; they might never be used again!
If gets yet even more complicated when we look at demand paging of applications; even apps don't get loaded into memory in one chunk, the pages get loaded in as needed. Processes can start faster, less RAM is used and it makes shared pages (eg common pages of libc that might be in many processes) even more efficient (it's already in RAM). It also means that the kernel could just _drop_ pages (don't send them to swap) and reload them from the original executable if the page is ever needed again.
And then we run into what failure mode you want to tolerate. For some people having the OOM kill a process and generate a hard failure is sometimes more preferable to reduced performance ("why is it taking me 10 seconds just to get the login prompt on the console? Oh, the machine is swapping to death..."). Think of a cluster of web servers behind a load balancer; having the webserver die (and so drop out of the load balancer much much quicker) might be preferable to having it take forever to respond to an API request (a load balancer health check might succeed where an API call might time out because that needs more backend resources).
So how much swap do you need? It depends :-)
Different people have different use cases. Swapon tells me 142MB used out of 1GB. cat /sys/class/block/$SWAP_DEVICE/stat third number shows about 280MB of reads in 22 days of uptime. If I had turned off swap I would not have noticed. (Swap file vs partition? The partition gets me stats and a possibly false sense of security that a swap file will not make the next file system corruption day worse than it needs to be.)
What if I had created an enormous swap partition? Each page of swap space uses a small amount of memory even if the page is not in use. With a big enough swap partition I could use up enough ram that I would actually need a swap partition. Showing my age: a swap partition big enough so tmpfs could hold a DVD ISO image would have eaten a significant fraction of my first PC's memory. Page sizes and virtual address sizes have changed over the decades so I do not know what the numbers are any more. Even with 8GB ram on this computer it has not been worth the effort for me to find out.
Now imagine something goes wrong and starts eating huge amounts of memory. With lots of swap space the system thrashes the disk but keeps grinding along slower and slower as more and more time is wasted swapping data between ram and disk. With a small amount of swap the required amount of memory will quickly exceed the limits of swap space. The Out of Memory killer will rear its ugly head and kill some task. Possibly the one using too much memory. Possibly the one you have been using hard for three hours without saving the changes. The good news is that if the OOM killer gets the wrong process it can kill other things until it gets the right one.
Consider your use case then pick your nightmare.
Why can't the industry standardize on paging for (typically) 4096-byte virtual memory pages moving in and out of real RAM (main storage in mainframes) while swapping is for process spaces to be rendered non-dispatchable with no in-flight I/O to be swapped out? The article would have been so much easier to read if the usage had been defined up front. Maybe we need new terms for swapping and paging to arise that adhere to these distinctions and end the confusion.
Do you mean standardize the terminology or in respect to the 'Z'? Moving from/to permanent storage or from/to RAM is the difference regardless of what the bytes represent. As for the 'Z' in ZRAM, it's basically for OEMs trying to lower costs by including less RAM. Now if you could also dedupe in RAM that might change things, but that would be a noticeable performance hit without new CPU instructions being added and possibly a tweaked PCIe (which the article doesn't mention).
After re-reading your comment, I think you're using 2 examples that use different context :-/. Of course it depends on your context of "swapping", but I feel like the article is using the context of 'swapon /swapfile'
As Linux overcommits memory so hard it always says yes to bloatware that requests 1TB of memory via malloc() (via glibc which calls mmap), unsurprisingly you soon run out of memory as soon as the bloatware start burning through dozens of GiB of RAM and there's nothing that can be done - as there's no memory available to allocate to switch to a tty or call oom_kill.
There is the oom_reaper, but in a typical Linux fashion, it usually either kills the wrong program and then there's no memory left, or it activates after when there's no memory left (it also does inane things like free graphics memory (that will be allocated immediately again), but not actually kill any process, despite there being a processes obviously using too much memory).
There are programs such as earlyoom, systemd-oom and nohang that actually implement OOM killing correctly and therefore "magically" prevent 99% of OOM's (which can actually be configured to avoiding killing the wrong programs, such as X or the screen locker - programs such as xscreensaver can be quite memory-intensive (but not really that much), which Linux can kill despite obviously not being the problem).
Linux can be configured to not overcommit memory with vm.overcommit_memory=2, but that means that malloc() and realloc() will fail if there isn't that much memory available (which properly written programs can handle by using less memory, but bloatware won't run, as such programs exit or hang if malloc() fails, as malloc() always succeeding is typically assumed for such programs).
I suspect the only way GNU's going to finally get a decent kernel is if I finish Hurd.
SysRq-F is probably failing because most distributions have SysRq kill commands disabled by default (for security reasons, so people cannot just bypass lock screen via them).
If you test SysRq-F or SysRq-I, while the system is operating normally it will probably fail too.
To enable it, set something like `kernel.sysrq = 244` in sysctl [1].
Also, in my experience, it hasn't actually been swapping freezing my system, but rather page cache eviction of actively used libraries and executables from memory when swap is exhausted (when RAM is very low when swap disabled), but I'm spoiled with an NVMe drive and that might make a difference.
[1] https://docs.kernel.org/admin-guide/sysrq.html#how-do-i-enable-the-magic-sysrq-key
Back in the days of database servers we set ours up with one small drive for the OS; another small one for swap; another for code, forms and reports; a biggish disk (set for dedicated contiguous space) for the data; and a fast drive for the transaction logs. At the prices that Oracle, IBM, etc were charging for DB licences the cost of the extra hardware looked pretty small.
Unfortunately we had to as we could no longer source the drums even when the magnetic core† was still available.
Swapping to ½" magnetic tape was apparently a thing in the dim past - so I was told once (also now in the only slightly less dim past) although the piss might have been taken.
† core was still used in industrial contexts well into the 1980s because it was non·volatile and I suppose physically robust.
Can confirm. Ran software on military hardened Hughes 4118 with core memory "The core storage capacity is 81,920 words with provision for growth up to 131,000 words."
Utility program read IBM punch cards into core memory until full, then output to mag tape. Used two mag tape drives to sort the 'data on tape' since 8K core memory was not sufficient to hold all the data.
ZX 81s and Spectrums - limited storage, very limited RAM, which meant programmers had to be super efficient and creative in equal measure to produce awesome games such as 3D Monster Maze and The Hobbit
For the last few years coders have reversed the roles: they can write apps as inefficiently as they can get away with knowing that the punter will have to upgrade to accommodate their bloated games and apps
Perhaps the current crisis might focus the minds somewhat, although I doubt it
The "If you use Hibernation, your swap must be bigger than your total RAM." rule is no longer true these days. For starters, Linux only saves active, non-cache pages to disk, second Linux uses compression when writing the hibernation image to the swap partition/file, which results in anywhere between 30-50% savings. So you can actually get away with having a small swap (of course, relative to your actual RAM usage).
I've tried to install enough RAM to avoid swapping to disk ever since I switched to a Solid State Drive. I did this out of fear that the frequent block erase/rewrites from swapping to disk would use up my SSD's erase/write cycles. Is running out of erase/write cycles no longer a concern for SSDs?
I'm amazed (not in a good way) at the recommendation in this article to disable disk encryption and swap/paging encryption. On any computer which is a real theft/loss risk (read, any portable device, and any device in a crime-prone place), unless the data you process on the device is simply not of concern to you (nor to anyone also to whom it might pertain), NOT encrypting everything is:
1. for personal use, a bad practice;
2. for any kind of professional or commercial use, quite probably a violation of applicable privacy law.
The adorable old xkcd comic notwithstanding, theft and loss, and the privacy/ confidentiality issues they raise, are very real issues, and for any but the most politically/ commercially sensitive (extremely small percentage) among us, much, much, MUCH more likely than "rubber hose cryptography". (See: https://www.schneier.com/blog/archives/2008/10/rubber_hose_cry.html , thank you Bruce)
> I'm amazed (not in a good way) at the recommendation in this article to disable disk encryption and swap/paging encryption.
Yep, and I stand by it. I think it's a bad plan.
The modern TPM2 implementations render it moot by just unlocking the machine at boot on their own.
If you are seriously worried about it, if you work with legally-sensitive stuff, then have a separate `/home` directory -- which I always recommend anyway -- and encrypt that and only that. Don't use the TPM chip.
