lkml.org 
[lkml]   [2009]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Memory overcommit
Date
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


\
 
 \ /
  Last update: 2009-10-30 11:51    [W:0.984 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site