Re: [PATCH] Remove OOM killer from try_to_free_pages /all_unreclaimable braindamage

From: Thomas Gleixner
Date: Thu Nov 18 2004 - 10:03:32 EST


On Thu, 2004-11-18 at 07:01 -0300, Werner Almesberger wrote:
> > Too often at present the machine just doesn't know what to do,
>
> See, that's exactly what I mean :-) So, why not just tell it ?
> "Hey, things are going to get a little rough for a while. Why
> don't you take a nap on that comfty swap disk while I clean up
> the house ?"
>
> > [ * I just looked it up: "of, relating to, or resembling the mental or
> > emotional state believed induced by the god Pan". Cool ]
>
> Hmm, you're suggesting we follow Morpheus instead of Pan then ?
> And I always thought the OOM killer was more like Eris' work :-)

Hmm, what about embedded boxes without swap ? There you have only one
choice. Kill anything appropriate.

I tested Marcellos, Andreas and Andrews changes and they all change the
trigger of the oom-killer to prevent the spurious unneccecary kills. But
in the case where an oom-kill is neccecary I still need my modifications
to the whom to kill decision and to the oom-killer itself.

1. Not to kill the innocent and maybe important processes like sshd

This one is solved by taking the childs into account.

2. To prevent overkill.

This still happens with all the modifications I have tested.
The szenario is that two processes request memory in an OOM situation.
The first caller to oom-kill is making room and then the second one is
also going to kill something.

The oom-killer must be protected against reentrancy and it must check
for the free memory level before finally doing the kill.
See my previous patch in this thread.

BTW, I found out that hackbench is a quite good replacement for my real
application in triggering these corner cases. Just increase the number
of processes until you reach the limit of the machine.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/