The big problem here is that when you run out of memory you can't
necessarily swap in that userspace program. Even an often-polling
program may be swapped out or dropped from memory shortly
before OOM. You could modify the kernel to give your OOM killer
preferential treatment - but you might as well put the program in the
kernel in that case, because you are:
1) modifying the kernel anyway
2) Keeping the OOM killer in memory all the time - i.e. memory
consumption as bad as a "bloated" kernel containing the OOM killer.
> poll /proc every few milliseconds (overhead would be minimal) and if it
> detects a problem (say memory usage going above a certain percent) it
Why poll - the kernel knows *precisely* when it runs out of memory.
If we want a userspace program for that, create a device that
blocks until OOM and have the userspace program read from that device.
But I don't think you can run it - it will probably be swapped out
by OOM time.
Another problem is that the kernal will OOM *between* your polls.
What should it do in the meantime? It could try to schedule
other programs, not knowing which one is the OOM killer. And most
scheduling attempts would probably just hit OOM again as the
programs are swapped out already.
> would perform whatever it is designed to do (I don't want to start
> rehashing all the ideas everyone has had, so I'll just say the
> advantages of implementing it in user-space:
[some reasons deleted]
> 3: A running program could be replaced with a different one on the fly
> without having to reboot or recompile the kernel.
A module for OOM-handling is equally on-the-fly-replaceable.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/