Hacker News Reader

Comment by flashback2199 | Hacker News Reader

RAM isn't user friendly in Linux. Ubuntu Desktop is the most popular distro by far by Google Trends, but it doesn't even come with RAM compression set up out of the box, so as soon as you run out of memory the UI totally locks up until the task killer kills a process, which always takes minutes in my experience. Pop OS does come with RAM compression set up, which is Ubuntu based, but then you're stuck on xorg instead of Wayland right now, because they decided to make their own DE from scratch in Rust for some strange reason, which isn't available yet. You can set up RAM compression yourself, but when macOS and Windows both have it standard, coming to Linux as a newbie so you install Ubuntu Desktop and your whole system locks up as soon as you run out of physical RAM, it's really odd and unexpected. I'm not even sure who would want to run a desktop distro without RAM compression.

View on HN

RAM compression is not magic.

It does allow you to save RAM and might prevent you from hitting swap for a while longer, but it won't save you if your working set is just too large and/or difficult to compress. Apps like web browsers with multiple tabs open might be easier to compress, a game with multiple different assets that are already in a variety of compressed formats, less so.

The Linux Kernel also has a bunch of optimizations (Kernel same-page merging, for example, among others) that do not require compression(although you could argue that same-page merging _is_ a form of compression).

The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.

> which always takes minutes in my experience

It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.

I have always found Linux to behave far more gracefully than Windows (OSX is debatable) in low memory conditions, and relatively easy to tune. Windows is a swapping psycho and there's little you can do. OSX mostly does the right thing, until it doesn't.

Didn't say it was magic. System slows down more as you use more RAM compression, so you have time to respond and close some apps. Without it I find I often am working at a thousand miles an hour, not noticing anything amiss, and then suddenly, brick wall, out of memory and I can't do anything at all.

Same page merging only works for KVM, as that's the only case that enables it without intervention that nothing else supports. It's MADVISE for everything non-KVM, and no applications are compiled with support for telling the kernel "hey, it's OK to dedupe me". The only way to get KSM to work with userspace applications is to use LD_PRELOAD to inject the necessary bits (https://github.com/unbrice/ksm_preload) or to use a custom kernel that has a patch and extra daemon to globally enable KSM for everything (https://codeberg.org/pf-kernel/uksmd).

I really wish this was a standard, configurable sysctl. There are many container environments (and heck, even browsers) that would benefit from this, and I cannot see any real downside.

> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.

I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.

> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.

Yeah. Exactly. But as the thread says, why aren't those things set up automatically?

As an additional data point, my usual OOM experience on Linux is also a completely frozen system until I get frustrated enough to power cycle the machine.

Has anyone transitioned from this being their observed behavior to something more tolerable? What did you change to avoid this problem?

Same here, for me this has been the most annoying issue when running Linux (much less now as I have much more RAM so I don't encounter the issue).

OOMKiller jumps into action pretty late. I'm on Fedora, thus running the systemd-oomd service, but even with this new service the system will lock up for a minute or two before the greedy process is killed.

I think with modern browsers, on memory constrained systems (think 4GB of RAM) this is easier to encounter than in the past. As someone who programs in Haskell from time to time I think I'm more familiar with Linux OOM behavior than most.

If someone wants to experience this easily with Haskell just run the following in ghci

    foldl (+) 1 [1..]

> Apps like web browsers with multiple tabs open might be easier to compress

Unfortunately harder than it looks; if you compress the JS heap the garbage collector may decompress it again when scanning for references.

>The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong.

I've never seen a Linux system not lock up on OOM. At work or at home the instant it starts swapping you might as well restart. Of course it has to kill the SSH daemon rather than the process using 98% of the memory.

>I have always found Linux to behave far more gracefully than Windows

Windows just gets sluggish for a few seconds. You can even still move the cursor when that happens!

I don't see how RAM compression helps address the machine locking up when it'll still lock up when the compressed RAM is used up. It just buys you a little more time.

Also, Fedora has had zram enabled by default for a few years now along with systemd-oomd (which can sometimes be too aggressive at killing processes in its default configuration, but is configurable).

Yeah you'd think it would make no difference but in my experience it does help a little. Don't ask me why.

But yeah even with zram my laptop still hard reboots 80% of the time when it runs out of RAM. No idea how people expect the Linux Desktop to ever be popular when it can't even get a basic thing like not randomly rebooting your computer right.

systemd-oomd is also default since Ubuntu 22.04. I remember it vividly because it effectively kept killing X when RAM filled up instead of sanely killing the process that last filled up the RAM, which is either gcc or firefox in my case. Absolutely user-unfriendly default configuration. I removed it and reinstalled earlyoom, which I have been using for years with a suitable configuration. I can only concur, RAM behavior isn't user-friendly on Ubuntu.

I second the earlyoom recomendation

it's a lifesaver

personally, i run my systems without swap, and kernel OOM behavior has been adequate.

Thank you for mentioning earlyoom - I'll install and try it because current behavior of total, complete lockup without ability to do anything besides reset with the hardware button infuriates me unbelievably. I really don't comprehend how something like this is possible and default behavior in 2023 in OS marketed as 'desktop' and 'casual/user friendly'

Had the same experience in the past with systemd-oomd, nowadays it does a better job at killing greedy processes than the entire user slice/scope.

Because it slows down as you use more RAM compression, so you have time to respond and close some apps. Without it you are working at a thousand miles an hour and then suddenly, brick wall.

> Because it slows down as you use more RAM compression,

Wait, are you claiming RAM compression uses an adaptive compression factor that compresses more as memory pressure grows?

Are you sure that's how it works?

In the case of zram, it reserves a portion of the physical RAM, and when the remaining physical RAM portion runs out, it begins compressing ram into the reserved portion. So the system slows down a bit as this compression starts happening. Nothing really adaptive about it to my knowledge but the result to the user is a noticeable slow down when there is high ram usage, which is a heads-up to me to close some stuff. Without it the system just locks up as soon as physical RAM is exhausted, without any warning, since it's fast up until that moment. Hope this makes sense. I'm not an expert on zram or other Linux RAM compression packages, so can't really answer questions about it beyond that.

Ah yes, the old, "you should enable swap so that when your RAM fills up, you know about it when the disk starts thrashing and all I/O grinds to a near-halt."

I mean, swap is useful, but that's not what it's for. Same is true for compressed RAM. If you want an alert for low available RAM, it seems like it would be better to write a script for that.

> disk starts thrashing and all I/O grinds to a near-halt

Nope, neither of those things happen when zram starts compressing ram. Nothing grinds to a near halt until the compressed RAM space is used up, it just slows down a little bit. Btw, compressed RAM via zram isnt swap, it's available as actual ram. It also increases the total amount of ram available. I don't think I need to make arguments in favor of ram compression since Windows and macOS both have ram compression by default.

I'm pretty sure what you're calling RAM compression is swapping to zram, in which case the answer is that Some people prefer to not swap at all because that will still make things janky in comparison to just killing things when you're out of memory. (I would endorse earlyoom for that)

I’ve heard this position multiple times, and yet every single benchmark I’ve seen repeated by teams of engineers in multiple contexts fails to replicate this fear. Zswap really is something that should just always be enabled.

How would you benchmark that?

For example, at Oculus they ran both performance benchmarks in a lab and collected feedback data from field telemetry. Now of course, it’s always possible some performance counter was overlooked / the degradation requires a specific workload to show, but the lack of ability to show any evidence of a difference implies that you probably are unlikely to see it given that the detractors were very vocal and engineering at big corps tends to be more stasis driven.

I saw this also repeated at Apple (not Zswap since not Linux, but similar idea of compressing pages) and Android.

For me it solved most of these lockups when using heavy ram apps (Electron, Firefox + Teams, etc) and keeps the system responsive. I am happy with it and plan to keep it enabled. I have no data to validate except that I don't remember having to SysRq key + F some app for a long time.

My point was that as a new user the default experience is unfriendly and saying that I have to understand the nuance between different ram related packages in order to talk about it is just proving my point.

I'm not saying that a new user should need to understand the nuance, I'm questioning whether your understanding of the underlying problem is accurate. I do agree that it's a poor experience for the system to freeze up under excess memory pressure, I just think the correct fix is less swap combined with earlyoom.

Gah I am so tired of explaining this in this thread: As the system begins running out of memory, it starts using more of the zram. The zram is compressed which uses CPU and slows the system down enough to notice it during which time I notice and begin closing apps. The alternative, without zram, is it's super fast right until I run out of memory then bam my whole system locks up. Zram also effectively makes the total available ram larger because zram swap is actually useable whereas swap to disk is so slow the system basically locks up when you start depending on it as if it were ram. Just try it dammit! It takes a few mins to set up and open enough stuff to see the effects.

In addition to swap on zram, there's also zswap. zswap is not quite as good as swap on zram, but almost certainly is better suited to systems that you want to have be able to hibernate.

As the other comment says (but kind of hides) install earlyoom and point the config at whatever you reckon is the main culprit. It only needs done once and you can forget about it.

Edit: I should add, this is advice for desktops. If it's a server either resize or fix your service.

Reply on news.ycombinator.com