On Wed, Nov 01, 2000 at 10:03:27PM +0100, Yann Dirson wrote:
> On Wed, Nov 01, 2000 at 02:59:01PM -0200, Rik van Riel wrote:
> > it appears there has been amazingly little research on this
> > subject and it's completely unknown which approach will work
> > "best" ... or even, what kind of behaviour is considered to
> > be best by the users...
>
> Sounds to me like a good point to favour a config-time selection of
> OOM killers.
Better yet: Apply my OOM-Killer-API-Patch[1] and build your own
OOM-Killer!
Just lock your module into memory, supply an function to
install_oom_killer(), save the old one (you get it as return if
installing it went ok) and be happy.
And now have fun bringing your machine into OOM situations.
Want to change it back? No problem. Just get signaled somehow[2],
reinstall the old one, unlock your module and wait to be cleaned
up.
I never tried it above Riks 2.2.x-OOM-Killer-Patch, but it should
work on top of it, because oom_kill.c isn't all that different.
Regards
Ingo Oeser
[1] http://www.tu-chemnitz.de/~ioe/oom_kill_api.patch
[2] if you don't know that much about the kernel, you shouldn't
play with oom-handlers anyway ;-)
-- Feel the power of the penguin - run linux@your.pc <esc>:x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Nov 07 2000 - 21:00:13 EST