On Sun, 12 Mar 2000, Rik van Riel wrote:
> On Sun, 12 Mar 2000, Peter Zaitsev wrote:
> > > It's not so. SOME solution is easy enough. But is it right solution ?
> > > This is unclear. To many peoples ANY solution where ANY process can
> > > be killed is "not right" -- theonly proper solution will be one where
> > > you'll get NULL from malloc when there are not enough memory.
> > HM. Does not malloc return NULL if it's out of memory now ?
> Indeed. This has the interesting property of killing
> (usually) klogd and syslogd and up to about a dozen
> critical system programs before (maybe) catching the
> When malloc() returns NULL, processes will die. We'd
> better kill the memory hog before something critical
In other words, we should try to detect malloc() ABOUT to return NULL, and
use that as a cue to find and kill the process using the most VM, then
retry the malloc() call? Sounds like the best solution, IMHO.
* Code to trap memory allocation failure (kernel)
* Code to find and kill most suitable process (user-mode?)
* Interface between the two (e.g. /dev/problem?)
I'd prefer to keep the killing code user-mode, so it is easier to debug,
test, change etc., and keep the interface as generic as possible - we
could extend it to include other problems later.
I can code the user-mode end, and some of the interface bit, but I think
the MM hook itself needs someone else...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:21 EST