Linux has nasty problem of paging everything out on disk IO. My dev system has 32GiB RAM, copying somewhat around 100GiB from one HDD to another via NTFS-3g after half a hour made system barely usable, it still had considirable amount of free and usable mem (around 16GB), but desktop processes have been paged out.
Announcement
Collapse
No announcement yet.
Fedora 32 Looking At Using EarlyOOM By Default To Better Deal With Low Memory Situations
Collapse
X
-
Originally posted by birdie View PostWe need a solution which works without user intervention. The kernel could be the best place for this feature but kernel developers seem not to care about this issue as much as it's crucial and now we already have at least four user space daemons for the task.
Comment
-
Originally posted by 144Hz View Posthalo9en They are working on that as well. Or working around since the problems are kernel related.
https://gitlab.gnome.org/GNOME/mutte...e_requests/923
Comment
-
Originally posted by rastersoft View Post
Four???? Can you point me to them? (just curiosity)- https://github.com/rfjakob/earlyoom earlyoom
- https://github.com/hakavlad/nohang nohang
- https://github.com/facebookincubator/oomd oomd
- https://gitlab.freedesktop.org/hades...emory-monitor/ low-memory-monitor
- Likes 1
Comment
-
Originally posted by 144Hz View Posthalo9en They are working on that as well. Or working around since the problems are kernel related.
https://gitlab.gnome.org/GNOME/mutte...e_requests/923
Comment
-
Originally posted by blacknova View PostLinux has nasty problem of paging everything out on disk IO. My dev system has 32GiB RAM, copying somewhat around 100GiB from one HDD to another via NTFS-3g after half a hour made system barely usable, it still had considirable amount of free and usable mem (around 16GB), but desktop processes have been paged out.
I am pretty sure it will fix your problem.
- Likes 1
Comment
-
Originally posted by k1e0x View PostWhy not just fix the kernel's OOM killer? Other OS's don't hang up like Linux does in that situation.. Wait.. I know.. systemd-oom-bandaid.
Comment
-
Originally posted by tildearrow View PostWhy not disable paging executable code out at all and making it resident on memory at almost all times? Because this may be the cause according to a few users in a former thread.
Comment
-
Originally posted by birdie View Post- https://github.com/rfjakob/earlyoom earlyoom
- https://github.com/hakavlad/nohang nohang
- https://github.com/facebookincubator/oomd oomd
- https://gitlab.freedesktop.org/hades...emory-monitor/ low-memory-monitor
Comment
-
The whole idea of OOM is wrong. The user doesn't want his process killed. When building a distribution with Yocto I want it built, even if it tries to build gcc and nodejs each with 8 threads simultaneously on a quad core + HT cpu.
What actually needs to be done is restrict the number of swapin. This can in theory be implemented in the scheduler.
That this will work can easily be verified by stopping (SIGSTOP) the offending process. It will get swapped out by the remaining processes, but not swapped in again and everything will return to normal. SIGCONT will continue it again.
Of course the process needs to be allowed to run longer then the swapin time needed.
Comment
Comment