Messages in this thread | | | Subject | Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage | From | Thomas Gleixner <> | Date | Thu, 18 Nov 2004 15:44:38 +0100 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |