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.
--
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