Timeline for OOM killer doesn't work properly, leads to a frozen OS
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 30, 2022 at 22:51 | comment | added | qwr | Project repo github.com/rfjakob/earlyoom | |
| Feb 19, 2021 at 8:38 | comment | added | ceremcem | Tested, it works nicely. github.com/rfjakob/earlyoom/issues/242#issuecomment-781903731 | |
| Jan 22, 2021 at 0:33 | comment | added | X.LINK | Best way to fix it is that kernel developpers do something to force the kernel to stay in RAM whatever happens. That, or even forcing everything that was in RAM when you've just booted to the desktop, to the RAM at all times. We do have early-oom and systemd-oomd, but you can still easily get a system freeze since it's based on how much percent of RAM is left (we can still OOM with only 70% of your RAM used, or even less) instead of killing the biggest non-system process that starts to trash I/O because Linux still really can't calculate the real amount of unreclaimable cache/buffers. | |
| Sep 1, 2020 at 3:24 | history | answered | alexei | CC BY-SA 4.0 |