Messages in this thread | | | Date | Wed, 28 Oct 2009 15:20:15 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: Memory overcommit |
| |
On Tue, 27 Oct 2009 23:17:41 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> On Wed, 28 Oct 2009, KAMEZAWA Hiroyuki wrote: > > > All kernel engineers know "than expected or not" can be never known to the kernel. > > So, oom_adj workaround is used now. (by some special users.) > > OOM Killer itself is also a workaround, too. > > "No kill" is the best thing but we know there are tend to be memory-leaker on bad > > systems and all systems in this world are not perfect. > > > > Right, and historically that has been addressed by considering total_vm > and adjusting it with oom_adj so that we can identify memory leaking tasks > through user-defined criteria. > > > Yes, some more trustable values other than vmsize/rss/time are appriciated. > > I wonder recent memory consumption speed can be an another key value. > > > > Sounds very logical. > > > Anyway, current bahavior of "killing X" is a bad thing. > > We need some fixes. > > > > You can easily protect X with OOM_DISABLE, as you know. I don't think we > need any X-specific heuristics added to the kernel, it looks like the > special cases have already polluted badness() enough. > It's _not_ special to X.
Almost all applications which uses many dynamica libraries can be affected by this, total_vm. And, as I explained to Vedran, multi-threaded program like Java can easily increase total_vm without using many anon_rss. And it's the reason I hate overcommit_memory. size of VM doesn't tell anything.
Thanks, -Kame
| |