[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1009152300380.25200@chino.kir.corp.google.com>
Date: Wed, 15 Sep 2010 23:36:21 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, oss-security@...ts.openwall.com,
Solar Designer <solar@...nwall.com>,
Kees Cook <kees.cook@...onical.com>, Al Viro <viro@...iv.linux.org.uk>,
Oleg Nesterov <oleg@...hat.com>, Neil Horman <nhorman@...driver.com>,
linux-fsdevel@...r.kernel.org, pageexec@...email.hu,
Brad Spengler <spender@...ecurity.net>, Eugene Teo <eugene@...hat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH 1/4] oom: remove totalpage normalization from
oom_badness()
On Thu, 16 Sep 2010, KOSAKI Motohiro wrote:
> Current oom_score_adj is completely broken because It is strongly bound
> google usecase and ignore other all.
>
We've talked about this issue three times already. The last two times
you've sent a revert patch, you failed to followup on the threads:
http://marc.info/?t=128272938200002
http://marc.info/?t=128324705200002
And now you've gone above Andrew, who is the maintainer of this code, and
straight to Linus. Between that and your failure to respond to my answers
to your questions, I'm really stunned at how unprofessional you've handled
this.
I've responded to every one of your emails and I've described the power of
oom_score_adj as it acts on a higher resolution than oom_adj (1/1000th of
RAM), respects the dynamic nature of cgroups, provides a rough
approximation to users of oom_adj, and an exact equivalent of polarizing
users of oom_adj, which is by far the most common usecase.
That feature, as is the entire oom killer rewrite, is not specific in any
way to Google, which I've stated many times, yet you constantly insist
that it's so. Yes, we deal with oom issues on scales you've never seen.
And instead of carrying internal patches to fix it since oom_adj is _only_
useful for polarizing a task and not relative to others competing for the
same resources, I reworked the entire heuristic from scratch since we're
not the only ones who want a sane priority killing.
We are not the only ones who add mems to cpusets, adjust memcg limits, add
nodes to mempolicies, or use memory hotplug. oom_adj would require a new
value whenever you did any of those for a static priority. The fact that
you constantly ignore is that the amount of memory that an aggregate of
tasks can access is _dynamic_ and so the kill priority will change unless
we define it as a static value that has a unit as a proportion of
available memory as oom_score_adj does. Nobody cares about static oom
scores like you introduce here with the revert; static oom scores mean
_nothing_ because they are only useful in comparison to other eligible
tasks.
You never respond to any of this, but you just keep pushing your same old
revert. You never responded to my email to Andrew that showed how this
isn't a regression, so I guess I can only ask Linus to read the same
email since you're pushing it to him now
(http://marc.info/?l=linux-mm&m=128393429131399).
I really hope we can put this to rest because it's frankly getting old
competing with a broken record.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
