On Fri, 3 Nov 2000, Ingo Oeser wrote:
> 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.
Ingo,
Maybe you could change Rik's oom killer to be a "module" of your OOM
killer API?
With this in place, its easier for people to compare Rik's OOM killer
with other possible new algorithms.
-
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:14 EST