> In my test, OOM seems to work well most of the time, but not always. When
> in works, it works fine, that is, it doesn't kill applications too early,
> and (in recent kernel), multithreaded applications (like mozilla and
> staroffice) and fully wiped from memory ("old" 2.4.x kernels didn't kill
> all the threads, just the selected process ID).
>
> When OOM doesn't work, the disk starts spinning like crazy, responsiveness
> in null, mouse doesn't move, consoles don't update, unability to switch to
> text consoles, etc. Giving time to the machine to recover itself is not
> helpful: after more than 15 minutes the disk continue to spin and sound
> like they were to inmediately crash :)
Seems to me you aren't necessarily OOM, that's why the killer don't
kick in. You simply have a working set larger than RAM, and is
trashing into a hopeless slowness. This slowness may even postpone
further allocations so you need more time to go OOM.
If you _want_ to get OOM killed quickly - allocate way too much memory
but keep the working set small.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/