le9-patch VS earlyoom

Also, are you using a stock kernel? Try using this patchset https://github.com/hakavlad/le9-patch and more specifically set this

This kernel patch work really well: https://github.com/hakavlad/le9-patch/

Oh that’s a known problem. There are many patch sets floating around that fix it by triggering the OOM killer when the system is thrashing: https://github.com/hakavlad/le9-patch

I’ve never ran into this specific problem back when I was daily driving desktop Linux, but I did run into 1000 similar ones that needed bandaid solutions. It’s death of a thousand cuts: https://news.ycombinator.com/item?id=28490753

I actually do use the Zen kernel already. If you are already using the zen kernel , make sure to use the latest one which has le9 patches , imho this patch can Improve user experience in tight memory situations. Check this https://github.com/hakavlad/le9-patch, saw many people praise this , but ymmv. Best of luck

- Limit the amount of thrashing or protect some pages from being reclaimed. This has been proposed by Google first and several other people since then, but AFAIK it has never been implemented in the mainline kernel.

Regarding the latter solution, there is a patchset called le9-patch[1] that is included in some alternative Linux kernels and it should be relatively safe to use.

[1]: https://github.com/hakavlad/le9-patch

Patch i was talking about le9-patch. it's only a proof of concept with very rough edges, but consider it isn't written by an experienced kernel developer with deep knowledge of memory subsystem.

> 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?

It's not that simple: some defaults may differ, and some features may arrive at different times (if ever). For example, earlyoom has been enabled on Workstation since F32, but the KDE Plasma spin got it one release later.

Most answers will answer your question, but you can do better and avoid the freezes in the first place. IME almost every time the system froze up and didn't come back in a few seconds it was out of memory. The obvious solution is to add memory, but you can use Early OOM to kill hungry processes if you're running out of memory instead.

It sounds like you're running out of memory though, so if your OS's OOM killer isn't working as well as it should, you can try earlyoom as an alternative.

Swap is indeed supposed to prevent this AFAIK. You can though try some tools like EarlyOOM and see if it helps : https://github.com/rfjakob/earlyoom