by > In this case,
> either the process grows very quickly, or is just plain big. I think the
> out-of-memory killer should target big or growing processes. If it doesn't
> hit the correct process the first time, it will free up a lot more RAM
> than it would otherwise, and it would be likely to get it right the second
> time.
about making automatic selections like that. Wouldn't it be
much better to just tell a process that makes a memory request
that won't fit that it can't have it? The process can then
decide on it's own if it is capable of continuing or aborting.
The real solution lies in getting rid of over subscription and
properly returning NULL for memory allocations when RAM+SWAP
has run out. To me this is a kernel memory subsystem issue.
When the X font server requested that huge block of memory it
should have been told you can't have it as there is no way it
would fit within RAM+SWAP-other processes. No need to kill a
process.
--
| Buzzwords are like annoying little flies that deserve to be swatted. |
| "Linux, the OS Microsoft doesn't want you to know about.". |
| -Bryan Andersen |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/