[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090803211112.CC23.A69D9226@jp.fujitsu.com>
Date: Mon, 3 Aug 2009 21:12:53 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: kosaki.motohiro@...fujitsu.com,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Paul Menage <menage@...gle.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [patch -mm v2] mm: introduce oom_adj_child
One mistake.
> > > And, May I explay why I think your oom_adj_child is wrong idea?
> > > The fact is: new feature introducing never fix regression. yes, some
> > > application use new interface and disappear the problem. but other
> > > application still hit the problem. that's not correct development style
> > > in kernel.
> > >
> >
> > So you're proposing that we forever allow /proc/pid/oom_score to be
> > completely wrong for pid without any knowledge to userspace? That we
> > falsely advertise what it represents and allow userspace to believe that
> > changing oom_adj for a thread sharing memory with other threads actually
> > changes how the oom killer selects tasks?
>
> No. perhaps no doublly.
>
> 1) In my patch, oom_score is also per-process value. all thread have the same
> oom_score.
> It's clear meaning.
it's wrong explanation. oom_score is calculated from the same oom_adj.
but it have each different oom_score. sorry my confused.
> 2) In almost case, oom_score display collect value because oom_adj is per-process
> value too.
> Yes, there is one exception. vfork() and change oom_adj'ed process might display
> wrong value. but I don't think it is serious problem because vfork() process call
> exec() soon.
> Administrator never recognize this difference.
>
> > Please.
>
> David, I hope you join to fix this regression. I can't believe we
> can't fix this issue honestly.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists