oss-security September 2010 archive
Main Archive Page > Month Archives  > oss-security archives
oss-security: [oss-security] Re: [PATCH 1/4] oom: remove totalpa

[oss-security] Re: [PATCH 1/4] oom: remove totalpage normalization from oom_badness()

From: David Rientjes <rientjes_at_nospam>
Date: Thu Sep 16 2010 - 06:36:21 GMT
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

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.