The attached kernel patch (applied on top of 4.18.5) that I've tried, almost completely eliminates the disk thrashing(the constant reading of executable(and .so) files on every context switch) associated with freezing the OS and so, with this patch, the OOM-killer is triggered within a maxium of 1 second when it is needed, rather than, without this patch, freeze the OS for minutes(or just a long time, it may even auto reboot depending on your kernel .config options set to panic(reboot) on hang after xx seconds) with constant disk reading well before OOM-killer gets triggered.
Note: I don't recommend using this patch in production, without actual programmers saying that it's ok first. I'm not a programmer. Maybe some programmer could improve it?
I am using the patch currently inside a Qubes OS R4.0 Fedora 28 AppVM where I can easily reproduce freezing the VM's OS (+ the constant disk thrashing, seen from `sudo iotop` in dom0) without the patch, while attempting to compile firefox with 4000MB max RAM setting for the VM, and with the patch basically no freezing and little to no disk thrashing during the 1 second it takes for OOM-killer to kill the offending process(es).
The attached kernel patch (applied on top of 4.18.5) that I've tried, almost completely eliminates the disk thrashing(the constant reading of executable(and .so) files on every context switch) associated with freezing the OS and so, with this patch, the OOM-killer is triggered within a maxium of 1 second when it is needed, rather than, without this patch, freeze the OS for minutes(or just a long time, it may even auto reboot depending on your kernel .config options set to panic(reboot) on hang after xx seconds) with constant disk reading well before OOM-killer gets triggered.
More info as to why OS freezes with constant disk reading when running out of RAM, here: https:/ /unix.stackexch ange.com/ a/463469/ 306023
The patch is from inside this question: https:/ /stackoverflow. com/q/52067753/ 10239615
Note: I don't recommend using this patch in production, without actual programmers saying that it's ok first. I'm not a programmer. Maybe some programmer could improve it?
I am using the patch currently inside a Qubes OS R4.0 Fedora 28 AppVM where I can easily reproduce freezing the VM's OS (+ the constant disk thrashing, seen from `sudo iotop` in dom0) without the patch, while attempting to compile firefox with 4000MB max RAM setting for the VM, and with the patch basically no freezing and little to no disk thrashing during the 1 second it takes for OOM-killer to kill the offending process(es).