3 ms·
Interesting approach. I'm curious to try it out. After playing around with vm.overcommit_ratio, different swap sizes, earlyoom[1], and a few other variables,
by kevinoid 8y ago
Interesting approach. I'm curious to try it out.
After playing around with vm.overcommit_ratio, different swap sizes, earlyoom[1], and a few other variables, I still haven't found a happy medium between high memory utilization and low risk of swapping to death. vm.overcommit_ratio=0 is safe, but on systems where occasional swapping is tolerable and memory is limited (e.g. my laptop), I'd rather allow some overcommit.
The risk is that if many cold or unallocated pages get touched while the system is under high memory pressure, the system can become totally unresponsive. At the moment I use "Magic SysRq"+f to manually start the oom_killer, when possible. Obviously it's not a great solution. Is there some kernel tunable to keep the system responsive that I'm unaware of? What do you guys do for desktop/laptop systems?
1. https://github.com/rfjakob/earlyoom https://github.com/rfjakob/earlyoom