Messages in this thread | | | From | Thomas Fjellstrom <> | Subject | Re: Memory overcommit | Date | Fri, 30 Oct 2009 04:49:17 -0600 |
| |
On Fri October 30 2009, KAMEZAWA Hiroyuki wrote: > On Fri, 30 Oct 2009 02:10:37 -0700 (PDT) > > David Rientjes <rientjes@google.com> wrote: > > > - The kernel can't know the program is bad or not. just guess it. > > > > Totally irrelevant, given your fourth point about /proc/pid/oom_adj. > > We can tell the kernel what we'd like the oom killer behavior should be > > if the situation arises. > > My point is that the server cannot distinguish memory leak from > intentional memory usage. No other than that. > > > > - Then, there is no "correct" OOM-Killer other than fork-bomb > > > killer. > > > > Well of course there is, you're seeing this is a WAY too simplistic > > manner. If we are oom, we want to be able to influence how the oom > > killer behaves and respond to that situation. You are proposing that > > we change the baseline for how the oom killer selects tasks which we > > use CONSTANTLY as part of our normal production environment. I'd > > appreciate it if you'd take it a little more seriously. > > Yes, I'm serious. > > In this summer, at lunch with a daily linux user, I was said > "you, enterprise guys, don't consider desktop or laptop problem at all." > yes, I use only servers. My customer uses server, too. My first priority > is always on server users. > But, for this time, I wrote reply to Vedran and try to fix desktop > problem. Even if current logic works well for servers, "KDE/GNOME is > killed" problem seems to be serious. And this may be a problem for > EMBEDED people, I guess.
Whats worse is a friend of mine gets stuck with a useless machine for a couple hours or more when oom tries to do its thing. It swap storms for hours. Not a good thing imo.
[snip]
-- Thomas Fjellstrom tfjellstrom@shaw.ca
| |