I hope there will be an update where when my RAM gets full my PC doesn't freeze and becomes unusable... I remember that Linux and Windows do this in different ways and Windows doesn't have the problem.
This gripe (that I literally crashed out on recently after maining Fedora for the first time) is top of my list for annoyance/frustration with Linux as a desktop.<p>I now have btop permanently running in a Terminal and I habitually Alt-Tab to it to watch my swap. As soon as my free memory gets less than 1 Gb I kill any Firefox tabs (the memory black hole).<p>I know this won't be popular, but Linux people have some kind of Stockholm Syndrome on this. They tell you all of the obscure configuration files you have to edit, the additional programs you install. They insist that just having the OS kill a random program to save the DE is a good plan. It's the typical "your holding it wrong" mantra.<p>I run both Windows and MacOS and have done so for decades. I cannot remember the last time I had a hard freeze like I get on Fedora. On the exact same box running Windows I was able to have VS Code, Chrome with 15+ tabs, terminals, docker, etc. all running with zero issues. On Fedora I have a handful of Terminals and Firefox with less than ten tabs and nothing else running and I have to watch btop like a hawk.<p>The excuses people make are mind bending, and the shifting of blame from the system onto the user is shameful.
Which OS are you using? systemd-oomd (or similar) afaik is enabled in many modern releases and fixes it. The default settings (on Arch) make it kill stuff when your CPU is spending 60% of time on reclaiming memory over some time period. So you'll get 20 seconds of lag, then it is fixed.<p>By killing a program, yes, but how else do you expect it to work? If your RAM is not enough you have to kill stuff. And I really doubt you mean to say that Windows is _more RAM efficient_ than Linux, because that's kind of absurd. Maybe Firefox is less RAM efficient than Chrome.<p>Edit: MacOS I wouldn't doubt being better in RAM management than the others because they have been selling their devices with ridiculously low amounts of RAM for decades.
> how else do you expect it to work<p>How does it work on Windows and MacOS where I don't get the same freezes and random programs aren't killed by the OS? Because I'd expect it to work like that.<p>There is this false dichotomy, a black and white kind of thinking on display.<p>> And I really doubt you mean to say that Windows is _more RAM efficient_ than Linux<p>What I'm saying ought to be clear to anyone willing to listen. My system should not get into an unrecoverable freezing state when I am doing routine tasks on a fresh install of an OS. And the community that is supposed to champion this OS should not then shift the blame to me if I complain about it.
<i>"How does it work on Windows[..]"</i><p>This video from Mark Russinovich is a classic explaining it. It is old but still relevant.<p><a href="https://m.youtube.com/watch?v=AjTl53I_qzY&ra=m" rel="nofollow">https://m.youtube.com/watch?v=AjTl53I_qzY&ra=m</a><p><i>"My system should not get into an unrecoverable freezing state[..]"</i><p>There is a good precedent for what you want: Safety critical embedded systems. Your car ECU should not be in an unrecoverable freezing state when you want to break.<p>These embedded systems also are known to be terribly memory inefficient because every bit of memory is statically assigned and never reused.<p>So, it is not that what you want is impossible, it's just wasteful and expensive.<p>Linux and Windows sit on slightly different points on this spectrum (opposite of said embedded systems) and what you perceive as Windows' better behavior under memory pressure has a price too.
I get memory related freezes on macOS all the time.<p>And back when I was forced into running Windows, I used to get memory-related freezes daily. Literally daily.<p>So I’m really not convinced the situation is drastically different there. I mean if it were that simple, Linux would have fixed it already.
macOS shows a modal with a list of offending applications and how much RAM they're using. Some of those applications are "paused", marked in red, some are "not responding", and some are responding normally.<p>You can pick applications from that list and choose between "Resume" (for "paused" applications) or "Force Quit".<p>At no point the system becomes unresponsive.
Freeze as many applications as necessary to reserve room for the DE so I can choose what to do?<p>Surely that's obvious to other people aside from me. It's an attended system, not a headless server in a rack hundreds of miles away that must not ever alert someone.
Firefox is definitely more RAM efficient than Chrome, in my experience.
The ideal would be to go into swap without becoming unresponsive, so that the user can quit a program of their choice to free memory. If you <i>really</i> want to make an issue out of it, do something like pre-X macOS, where it would provide a warning when you are getting close to running out of memory, so that a user might have the chance to do something before the current process starts getting swapped out.
> The ideal would be to go into swap without becoming unresponsive, so that the user can quit a program of their choice to free memory.<p>Linux already does this. The issue is when your swap is full too, or you’ve exhausted your RAM at such a rapid pace that the disk IO cannot keep up with the read and writes to swap.<p>I’ve seen Windows choke under the same conditions too.<p>> do something like pre-X macOS, where it would provide a warning when you are getting close to running out of memory, so that a user might have the chance to do something before the current process starts getting swapped out.<p>This is where the desktop and the kernel being entirely separate organisations (not even projects, but literal organisations) makes things a touch harder. And those DEs aren’t even Linux specific either. So any tooling would have to portable (which, in fairness, should be possible with POSIX in this particular scenario).<p>I think KDE does provide tools here for gracefully handling memory constraints. But that’s just one desktop environment of many.
>> do something like pre-X macOS, where it would provide a warning when you are getting close to running out of memory<p>And I've run out of memory while compiling packages (I'm looking at you, composable-kernel) on Gentoo. It's not like it can notify me and I close things in the milliseconds it takes for a few more GCC processes to spawn and allocate and fault all the remaining memory.
Swap is extremely slow. And if running it on a high-end NVMe, you better hope you don't swap often.
Call me an old geezer but I remember having this thing called swap.
Same problem I've had. On a 24GB MacBook Air, I can have a VMWare VM, Lima and an IDE and a bunch of Chrome tabs loaded and the system is fluid.<p>Meanwhile if I try something similar on a 32GB Linux system, it will sputter or outright freeze. Suspend the system at 16GB used and on wakeup it takes 15 seconds to get back to full responsiveness.<p>Yes, some of this can be addressed with swappiness settings, however that behavior isn't partically clear and doesn't take into account that depending on your workflow on a given day (e.g. coding then video editing) different swap behaviors may be more optimal. Nor does it help for people who are trying to get good productivity out of a 16GB or lower system.<p>The one thing that has helped is moving to Brave Origin. Whether that's loading less JS ad SDKs or general optimization, it does seem to use a lot less ram than Edge/Chrome.
I'm ashamed to daily run Ubuntu at home with Chrome (a dozen tabs), Firefox (literally hundreds of tabs, but only a few active), Thunderbird, RSSGuard, whatever I'm currently working with, and sometimes Steam and a AAA game on top of that. Never felt the need to close anything, but I must confess I have 64 Gb of RAM.<p>At work I ran the same Firefox profile in Windows, with 16 GB of RAM, it used to eat RAM more eagerly, and restarting only helped for a few hours. I never understood why, but GMail and WhatsApp tabs were usually the biggest memory drains.<p>I'm just happy I don't have to deal with that anymore, since we were moved to iMacs at work, and the same Firefox profile gives no trouble with 24 Gb or RAM. WhatsApp is still the hungriest tab, but it stabilizes. Maybe there's a sweet spot between which tabs are opened and how much RAM do you have?
Just ask any of the last gen coding agents to fix this for you and they'll make a script that tweaks a few things and it just works.<p>Is it acceptable? No. Did it solve my endless crashes that I used to get every day? Yes.<p>I don't love Ubuntu, I just hate modern Windows and find my ubuntu for work popos for gaming setup to be better for me. Ymmv.
The Linux Desktop people have been singing the song of "works for me" for decades, which is as long as they've been unable to crack double digit users.
I mean, I'm to blame at the moment as well. I'm putting up with it because I don't want to use Windows, mostly because I'm doing a lot of agent dev and I saw them struggle in a Windows environment. And there is a little spite driving me since Windows 11 is full of ads and I felt like it was pushed on me when I wanted to stay on Windows 10.<p>The vast majority of my computer use has been on MacOS for the last 15+ years, since a Macbook Pro is the standard issue dev environment at every company I have worked at. I had a Windows desktop entirely for gaming that I've repurposed to be a Linux dev box. I genuinely thought all of the hype about Linux desktop that I have seen lately was an indication that it was finally ready for general use.<p>Now that I am vigilant watching RAM I haven't had the freezes. And I refuse to let the OS roll the dice on what program it wants to kill in its last ditch attempt to save itself from a problem it shouldn't have in the first place. And since Firefox seems to demand 800MB-1GB per tab process, it is a reliable scheme to just close heavy tabs when I see memory dip into the danger zone.<p>I just wish RAM wasn't so expensive right now, since I'd buy as much as I could just to avoid this pain.
Possibly an unpopular opinion on this forum, but virtual memory has always been one of the strengths of the NT kernel. (And integration between the cache manager, virtual memory manager, file system (NTFS), overlapped I/O, completion ports, and threading. It’s a very robust and performant foundation when leveraged correctly.)
Same. What I find pretty incredible is that we've had single core scheduling, then multi-core CPUs, page files, etc., all that stuff as computers progressed through the decades, just for a single app freezing the entire system in 2026.<p>Where did the technology go?
> I now have btop permanently running in a Terminal and I habitually Alt-Tab to it to watch my swap. As soon as my free memory gets less than 1 Gb I kill any Firefox tabs (the memory black hole).<p>This is what nohang [0] does. There is no reason to do that by hand. Obscure configuration files to edit?<p>Yeah it's kind of annoying that it's not built in to most desktop distros, but... literally `apt install nohang; systemctl enable --now nohang.service`. Hardly that difficult.<p>[0]: <a href="https://github.com/hakavlad/nohang" rel="nofollow">https://github.com/hakavlad/nohang</a>
So your saying the problem I am reporting is not a problem because it is obviously my responsibility to research the dozen available workarounds listed on internet forums, figure out which ones are not brand new footguns or genuine security risks, install sudo level programs from github that as the Warnings section on that repo confess "the daemon runs with super-user privileges and has full access to all private memory of all processes and sensitive user data;"<p>And then I scroll down and see the install instructions for my distro:<p><pre><code> > To install on Fedora:
>
> Orphaned for 6+ weeks, not available.
</code></pre>
It's funny I hear people slag npm all the time for developers just YOLO installing any dependency for the webservers they run.<p>But hey, just sudo install this package! What could go wrong? You only use your desktop to access your online banking, etc. Forget the trust mechanism of your distro and just live a little!
Have you tried setting up systemd-oomd [1]? It works by killing the offending process (hopefully) before a true OOM.<p>When I run in a frozen system because of RAM, I'm a happy user of the Magic SysRq 'f' [2], it bypasses most kernel scheduling so it works even on frozen systems<p>[1]: <a href="https://man.archlinux.org/man/systemd-oomd.8" rel="nofollow">https://man.archlinux.org/man/systemd-oomd.8</a><p>[2]: <a href="https://en.wikipedia.org/wiki/Magic_SysRq_key" rel="nofollow">https://en.wikipedia.org/wiki/Magic_SysRq_key</a>
Its not enabled by default, but enabling MGLRU setting /sys/kernel/mm/lru_gen/min_ttl_ms to 70 has entirely resolved the issue for me. It _does_ usually pick firefox or vscode to kill, but my system remains interactive, with no need for earlyoom.<p>Docs <a href="https://docs.kernel.org/admin-guide/mm/multigen_lru.html#thrashing-prevention" rel="nofollow">https://docs.kernel.org/admin-guide/mm/multigen_lru.html#thr...</a>
From my experience, Windows does freeze and become completely unusable too, just not usually from RAM usage hitting 100%.<p>I don't use Windows much, nor do I care much about that environment, but from what I've seen it seems to keep RAM usage below 100% most of the time. What I do see pretty often is the drive getting stuck at 100% usage instead, which makes the whole system ridiculously unusable anyway.
Windows does freeze and become unstable, but it's usually because of some ring 0 errors not getting trapped appropriately.<p>But Windows has always handled both OOM and out of disk space <i>very</i> well. The system will be extremely sluggish, but it typically continues operating.<p>The Linux design is to keep using memory, then push to swap, and then when you OOM you hard lock. The built in kernel OOM module can miss when RAM usage spikes rapidly. You can enable OOM monitors like systemd-oomd or earlyoom, but they do not run by default, and their behavior is to term the offending process.<p>The thing about Windows is that when you request memory, you're only granted memory if it can be guaranteed in the first place. The application will get a "not enough memory" error. On Linux, you're permitted to request more memory than the system actually has, with the idea that you won't actually use that much memory. It's optimistic that way. But if you <i>do</i> use it, then you're screwed.
Doesn't Windows, like macOS, automatically expand swap? You can't run out of memory nearly as quickly as you can on Linux. And at least on Windows I always figured this is why it felt so sluggish under load--it ends up paging alot. Not sure why macOS has always felt more consistent; perhaps the OS and major apps are less gratuitous memory hogs?
Linux can be configured to disable memory overcommit<p>sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=50<p>It is probably a bad idea to do that though as it will limit the amount of virtual address space an application can use
Note that the fork()/execve() semantics of Linux pretty much depend on memory overcommit. You may get weird OOM crashes when there is seemingly no memory pressure, if you turn overcommit off.<p>In the short time between fork() and execve(), the new process duplicates the entire virtual memory of the old one. None of this is physically allocated due to copy-on-write, but still all counts as virtual memory.
Haven't had Windows freeze on me for ages. I had a frozen linux server that ran out of RAM yesterday.
> I had a frozen linux server that ran out of RAM yesterday<p>This has so many variables that it's practically useless as a data point. We have a few Ubuntu VMs running complex business web applications and their Postgres database on only 4 GB or RAM and 20-50 GB of storage, no swap space. Ocassional high load, but Zero OOM problems for many years.<p>We could upgrade the RAM, but we were stingy when we created them, and it has worked well so far, so why waste resources? Incidentally, using no swap was a deliberate choice, as it would slow things down too much. We preferred to see and correct any memory/OOM issues beforehand, but fortunately we had none.
Use a windows server then :D
edit: I meant that regularly hitting OOM on a production server is usually more of a provisioning/resource-management issue. Obviously, how the OS handles OOM once it happens is still its responsibility.<p>Running out of memory on a linux server sounds more like a skill issue than something comparable to how a desktop OS should behave :\
Windows uses eager memory allocation, and applications will die when they allocate (and think image editor loads a beefy image) or fail to start when it runs out of memory.<p>Linux uses lazy allocation and overcommits, so what dies isn’t necessarily what you would expect thanks to the OOM killer.<p>With a fixed swap size windows doesn’t necessarily slow down as it runs out of memory.<p>YMMV if you don’t have 64 gigs of RAM and a 64 gig swap.
Windows will aggressively page out as you approach RAM usage, MacOS does the same but based on activity iirc. On Linux if you just set up paging (forgot how i did this on arch) you won't have any issues.
I have never had Windows fail so catastrophically as Linux does on OOM or disk exhaustion. Many distros probably still fail to boot with a full disk.<p>Linux OOM handling is just atrocious.
I just solved the problem by shoving 192GB of RAM into my desktop and 96GB into my laptop and called it a day.<p>Of course I did this when RAM was cheap but one of the best decisions I have ever made in life.
Me too, but you can improve the behavior yourself too. It's been an issue with desktop linux and the default settings for a long time. You could maybe tune OOM killer settings, but another option is to use a package like earlyoom: <a href="https://man.archlinux.org/man/earlyoom.1.en" rel="nofollow">https://man.archlinux.org/man/earlyoom.1.en</a>
For me Windows becomes unusable as soon as any of my drives is being hammered, including when it is swapping, but not limited to it.
Explorer freezes too when an external hard drive spins up, very annoying.
It's such a strange issue which existed in Windows for ages, even though on the surface it seems like it would be easy to fix.
Agreed. I've run into this way too many times, and now with a super aggressive oom killer config it still slows down until vscode or firefox just get closed. I wish it was similar to how it seems to be on MacOS from what I see on friends' screens, where theres some kind of hypervisor running that pops up a nice responsive GUI window saying "hey, xyz is using too much memory, close it or something else" while not locking up. But maybe that's also just the grass being greener on the other side?
Windows does freeze when a Chromium-based browser decides to hug the pc.<p>Chrome/Vivaldi are the only browsers where, when i have a long HN page open, when i resize it, my laptop freezes for like a minute. Not a full freeze, the mouse still moves, but like it's the year 1999 with a refresh rate of 4 seconds.
Wait, how does literally no one in this thread mention swap?<p>IME, many default installations in recent years don't configure swap by default. Dedicate a few tens-of-gigabytes on your hard drive and memory overflows there instead of borking.
Sometimes I use swap, but >half the time I'm intentionally disabling it so the system doesn't go into livelock. I'd rather have an OOM than an unresponsive system. Granted this is usually on some headless Linux machine running batch jobs, not my PC.
It only postpones the inevitable. It doean't actually fix it. I went for a 64 GB swapfile to hopefully not have to worry about it any more, only to find my swapfile full after a few days anyway, even when configuring swappiness to a minimum. Shit just piles up for no apparent reason. I'm sure someone smarter than me can diagnose the problem, but I just decided to reduce the swapfile size to a more sensible value and reboot every now and then. I should probably try Zram or whatever to see if that mitigates the problem.
Oh, that's just a garden variety memory leak.<p>Most applications these days are very good about that; you likely have just a single app that you use regularly that leaks. If you kill the process the memory will be recovered, save for some allocations the kernel maintains.
Solaris family kernels move this problem to run/allocation time, instead of waiting for the system to become unusable before trying to do something about it. Kinda nice
Just last night I was debugging some batch job on a Linux box making the machine go unresponsive <i>even though there's no swap</i>. User process taking all the RAM and the OOM killer doesn't stop it, instead the killer itself gets live-locked along with the ssh session or whatever else, so I can't just get in to look at it.
Configure overcommit_memory, overcommit_ratio, admin|user_reserve_kbytes, min_free_kbytes, oom_kill_allocating_task, oom_score_adj; if you're on a dev box make it such that even if you approach memory limits to just instantly start killing processes rather than swapping. It's not a solution for servers, but for dev environments it's basically perfect.
On servers with k8s the default is preempt based on prio, followed by oom kill and ‚newly’ memory qos:<p><a href="https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/" rel="nofollow">https://kubernetes.io/docs/concepts/scheduling-eviction/pod-...</a><p><a href="https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits" rel="nofollow">https://kubernetes.io/docs/concepts/configuration/manage-res...</a><p><a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2" rel="nofollow">https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#...</a> (New feature)<p>So normally if you overcommit it might be undefined behavior if you not have enough memory. However if everything is fine pods can preempt based on prio to new nodes.<p>With the right settings only the faulty app might fail. Without it it can be a real pain to find the rouges
Linux might freeze from occasional OOMs, but Windows is sluggish and unresponsive even when RAM is far from full with all its unnecessary background processes. That's the difference for me.
Totally fixable w a little configuration (ask Claude)<p>But yeah it’s completely ridiculous and frustrating that the default is to just lock up your DE
zswap and systemd-oomd/earlyoom are your friends.
earlyoom is what you're looking for. it'll crash the process instead of hang
That's because windows always uses swap by default, and your system will freeze if you run out of swap which is usually 33 gigabytes, or ir your drive and ram are full.
A lot of cargo-culted sysctl tuning blogs will get you there... Linux doesn't have that problem, your chosen distro/config does. E.g., CachyOS is tuned for absolute minimum latency and assumes you won't be heavily multitasking. Using that as a workstation requires adjustments.
I had this symptom due to having an SSD without a RAM cache, which caused the latency of disk access to rise to seconds under heavy paging, effectively freezing the computer. Enabling the kyber IO scheduler, tuned for responsiveness over throughput, solved it for me.
Are these directly comparable, though? Doesn't Windows default to using free space on the system drive to grow the swap file in case of memory pressure? Linux has you set up swap files/partitions explicitly.
Also the way memory allocation in Windows works is that if it doesn't actually have the physical RAM (extended by pagefile) then the program will crash.<p>If you disable pagefile (like I did for some of my servers) and your program mallocs more than what you have in available space (even without ever dirtying a page) you will observe this.<p>I'm sure that this helps Windows a lot, even if it's not counted as actually used until the page is dirty.<p>Linux programs very often have virtual addresses many times the amount of physical ram, because there's never been any restriction. It's then very easy to just malloc huge chunks and use what you need and don't care about it too much.<p>Especially with many "tiny" allocations, python for example has huge sized objects which consume gobs of RAM dynamically, so any long running python process not only fragments memory but ends up having a bunch of objects consuming virtual memory...<p>idk why I felt the need to rant about this, but it's a difference that I've noted.
Yes, Windows doesn't overcommit memory. In the default config Windows is allowed to grow the page file as much as it wants, and empty pages are cheap to reserve in the page file (no need to actually write those zeros, you just need to reserve space for them). So the end effect is comparable, with the difference that software shouldn't just go ahead and ask for gigabytes of memory it doesn't actually need<p>I prefer the Windows approach, it's more predictable and has better behavior under memory pressure. But it can cause issues with software written under the assumption that the OS uses memory overcommit
Windows absolutely does have this problem.
macOS too sadly. by the time you realise there's a problem the machine is already comatose and unresponsive<p>all these electron apps and invisible virtual machines (looking at you Claude) really don't help.
One of the biggest reason I migrated to Codex. I'd like to see each agentic CLI process as a simple building block, and having 100 claude session means I sometimes run out of memory (and I have 256GB of them). Codex never have this problem.<p>The communication is more direct too with GPT5.6 family of LLM. No more belt and suspenders.
Macs are also real bad at handling low disk space. I don’t how other OSes do but the best advice on a Mac is to always have a decent amount free.<p>What’s a decent amount? No idea. Don’t test it :)
I've also found that the fastest way to totally lock up a Mac kernel is to have some external hard drive fail while connected. You will be unable to open, quit, force quit, or reboot, and it won't boot up again unless that drive is disconnected.
Both MacOS and Windows start having issues if you have less than 10% of the disk free. The problem with the Mac is your ~/Library/Application support/ folder can get huge and take up a ton of space. Mine is currently at 55GB
When my Intel Mac ran out of disk space once, it became impossible to clear the space without rebooting (due to APFS's annoying journaling crap or whatever -- it would literally say "rm: can not remove [whatever]: no space left on device" or something), which caused Google Chrome to wipe all my local storage and cookies because it loves to do that when you run out of disk space, and there's no way to get that data back even if you do somehow clear space with the browser still running. I've been bitten by this many times on at least four different platforms. I wish it could just keep everything on disk instead of deleting it all? Like anything that deletes my data automatically can just go die in my opinion. This is one of the reasons I don't use Google Chrome anymore, another is how it deletes "old" history too (after 3 months) even if you have terabytes free, which is just so offensive I can't even explain it. Ungoogled Chromium lets you turn some of this stuff off, but when I moved to Mac I just started using Safari.<p>The only way to save my file system was to boot into recovery mode and run a verification with Disk Utility, then I was able to remove some files and get my space back.
This seems to always be explained in a confusing and sometimes wrong manner, so I may as well also try to explain it in a confusing and sometimes wrong manner too.<p>Both Windows and Linux allow applications to map memory in an uncommitted state. However, in Linux, uncommitted memory can magically become committed by simply trying to use it, whereas on Windows you have to first actually commit it with a separate API call.<p>You might wonder why you would even bother allocating uncommitted memory on Windows if you have to explicitly commit it later. Simple: just to reserve a contiguous slice of address space for later.<p>The consequence of this is that on Windows an allocation failure usually occurs at an API call where it can return a failure, and indeed does. On Linux though, an allocation can fail during a page fault that is entirely transparent to the application. So instead, the default behavior is to allow overcommit, where applications are allowed to commit <i>more</i> memory than the system actually has, under the assumption that in many cases it won't all be in use at once. Instead of an application hitting an error or crashing on a failed allocation, if there is no memory left, a process simply hangs.<p>Here's my take on why this is the way it is:<p>- Because programs are written without any knowledge of what memory pages are committed, applications will allocate physical memory pages transparently even if they didn't malloc or mmap anything. Because of that, when an allocation fails under memory pressure, it's pretty likely the first page to stall on overcommit isn't really related to the actual memory pressure.<p>- To try to mitigate this, during high memory pressure situations, mechanisms like the OOM killer have to score tasks based on several factors to try to guess which ones are causing the problem.<p>- When you have something like make -j running, it is pretty easy for it to choose Firefox instead of the 200 instances of Clang, since individually none of those Clang instances are really using much memory. This, of course, doesn't fix the bleeding, it just kills your browser. There are ways to mitigate this problem, but they are not often implemented and nothing will ever be perfect.<p>One may wonder if it is worth the trouble... Probably not, but it does have its advantages, particularly when it comes to databases and caches, which can aggressively reserve memory and mmap files and heavily lean on demand paging for memory management. It's just that in this case, managing memory pressure becomes somewhat heuristics-based, and tools like cgroups are often desired to isolate failure domains and control memory allocations in production systems.<p>This is a tough problem to solve. Many improvements to the Linux OOM situation have been made, from simply fixing problems that made the wedging even worse, to tweaking the OOM scoring, to usermode daemons like systemd-oomd that try to catch memory pressure earlier. However, so far this is a solidly unsolved problem - the same exact wedging is <i>still</i> possible today.<p>As hopeless as it seems, I am still open-minded here. The Linux desktop moves slow, but nonetheless it seems pretty good at overcoming challenging obstacles.
> Windows doesn't have the problem<p>Maybe not in the same way then.<p>Anyways, you've unlocked an old memory of mine, where Windows would crap itself due to low RAM and the fonts and interface elements would render in a "compatible" way, like using "fixedsys" font everywhere.
You've never been given a corporate laptop with MS Teams? Mine would literally prevent me from opening apps before it reclaimed memory from Teams...
Try changing the Linux scheduler. And yes most desktop OSs are garbage and won’t let you use the fucking keyboard when under load.
My experience is that if you have swap you better have a lot of it. Swapping is bad, but swapping and thrashing is a disaster.
zram can create a very good buffer for that sort of thing
Better use zswap, as zram and swap together can lead to priority inversion. <a href="https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html" rel="nofollow">https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-...</a> (found via lwn.net)
When my RAM gets full the kernel kills Firefox (3 profiles) so the PC becomes unusable, with lost data.
[dead]
I stopped using swap almost a quarter of century ago, and since then I have not seen a PC with Linux freezing because of full RAM.<p>Before the recent increase in RAM prices, it was not difficult to have a generous amount of RAM in a PC, that would make very unlikely the out-of-memory situations.<p>When OOM really happened, it was much better to become aware of this immediately, and reduce the number of concurrent threads for a running job, or whatever caused that, instead of having reduced performance or even freezing.
It depends on the memory conditions you end up in an OOM with. In some cases Linux starts to just trash swap and never kills anything because it thinks it can free a few pages at a sufficient tempo. This is where turning off swap helps by just forcing the OOM killer to act sooner. On other devices it can make things worse. In the end it's still all terribly handled by Linux.
Mannnnn.... I've done similar and have NOT had the same experience. The problems I've had are usually because I'm loading stuff in a weird disk-memory-cpu trifecta and they all <i>really</i> want to push the remaining 30GB stuff into a database. Then it's off to ctrl-alt-f5 to wait for gnome to crash so I can auth in and kill the ravaging process.
My PC doesn't have swap and it freezes for about 20 s when I run out of memory until the OOM killer finishes its job, usually by killing Code or more rarely Firefox. I'll take this over the machine swapping so slowly that I need to hard reset anyway, but I'd appreciate it if the OS could stay more responsive when it happens.
Unfortunately Linux makes it difficult to fully get away from swapping because any file-backed page is eligible to be evicted, and even if you have "disabled swap" the kernel will cheerfully page-out your program, even if it needs to be immediately paged in again to continue. The only way to stop it from doing so is to remap all executable mappings into anonymous memory, a thing which is possible but which the loader and linker do not make easy.
This type of thrashing was the most common OOM issue I saw on my servers, the system would effectively deadlock until I pulled the plug. In my setup this seemed to be caused by slow-ish disks, and using a small amount of zram made things more CPU-bound / less IO-bound. I haven’t seen the problem since, the OOM killer does what I expect.
I ran into this last night and learned about it. At 3am.