5 ms·
The few cases when Ive seen OOM invoked, it took couple of minutes to kill chromium after flash (of course) messed up, during that time the system was unrespons
by antocv 13y ago
The few cases when Ive seen OOM invoked, it took couple of minutes to kill chromium after flash (of course) messed up, during that time the system was unresponsive and it killed few random smaller processes until it hit the correct one, flash or chromium in some weird interdependent bug. Either way, I wasnt too happy.
After a while I noticed when the bug triggered/the system started becoming unresponsive, and I had a terminal with killall -9 chromium & killall -9 flash-plugin ready to go, so I could myself preempt it and OOM wouldnt get involved. There has to be better mechanism than OOM.
- BrainInAJar 13y ago> There has to be better mechanism than OOM. Like not overcomitting memory in the first place
- Piskvorrr 13y agoToo slow for the command to pass through the usual "X - WM - TE - shell - killall" chain? Try Alt+SysRq+f ; that, in my experience, is waaaaay faster for invoking oom_killer.
- pritambaral 13y agoHis issue is that oom_killer doesn't get it right straightaway. Alt+SysRq+f would still need multiple invocations before it gets flash. Personally, I do use Alt+SysRq+f since it predictably targets GMail-on-Chrome everytime on my system. That is usually enough on my desktop OS for me to jump in manually kill the offender. I can then just F5 GMail.
- Piskvorrr 13y agoEven so, in OOM situations, sysrq invocation is still an order of magnitude faster than killall invoked from a graphical terminal emulator. As for hinting to oom_killer: I have a script which searches for chrome and flash processes every minute, and sets their oom_score_adj in the high hundreds. This makes reasonably sure that oom killer will go after these processes first.