Messages in this thread | | | Date | Fri, 30 Oct 2009 08:48:36 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: Memory overcommit |
| |
On Thu, 29 Oct 2009 12:53:42 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> > If you have OOM situation and Xorg is the first, that means it's leaking > > memory badly and the system is probably already frozen/FUBAR. Killing > > krunner in that situation wouldn't do any good. From a user perspective, > > nothing changes, system is still FUBAR and (s)he would probably reboot > > cursing linux in the process. > > > > It depends on what you're running, we need to be able to have the option > of protecting very large tasks on production servers. Imagine if "test" > here is actually a critical application that we need to protect, its > not solely mlocked anonymous memory, but still kill if it is leaking > memory beyond your approximate 2.5GB. How do you do that when using rss > as the baseline?
As I wrote repeatedly,
- OOM-Killer itselfs is bad thing, bad situation. - The kernel can't know the program is bad or not. just guess it. - Then, there is no "correct" OOM-Killer other than fork-bomb killer. - User has a knob as oom_adj. This is very strong.
Then, there is only "reasonable" or "easy-to-understand" OOM-Kill. "Current biggest memory eater is killed" sounds reasonable, easy to understand. And if total_vm works well, overcommit_guess should catch it. Please improve overcommit_guess if you want to stay on total_vm.
Thanks, -Kame
| |