lkml.org 
[lkml]   [2015]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv2 4.3-rc6] proc: fix convert from oom_score_adj to oom_adj
On Mon 26-10-15 14:42:57, David Rientjes wrote:
> On Thu, 22 Oct 2015, Hongjie Fang (方洪杰) wrote:
>
> >
> > The oom_adj has been replaced by oom_score_adj in kernel,
> > but the /proc/pid/oom_adj is provided for legacy purposes.
> > When write/read a value into/from /proc/pid/oom_adj,
> > there is a transformation between oom_adj and oom_score_adj.
> >
> > After writing a new value into /proc/pid/oom_adj, then read it.
> > The return value is a different value than you wrote.
> > Fix this by adding a adjustment factor.
> >
>
> You're only looking at the output and seeing that it disagrees with what
> was written and ignoring _why_ it disagrees.
>
> It's because, as I already stated, oom_score_adj is the effective tunable
> for oom kill process prioritization and the legacy oom_adj had a different
> scale where a 1:1 mapping is not possible.
>
> All throughout the kernel, we report the effective value. We accept
> writes and the reads report the effective value. This is no different.
>
> Nack again.

I really fail to understand your reasoning. The patch basically fixes up
the presented value of oom_adj after rounding imprecision. It doesn't
change the way how the oom_adj->oom_score_aj mapping is done at all. All
it does is that it presents oom_adj1 -> oom_score_adj -> oom_adj2 and
oom_adj1 = oom_adj2

How can this be any harmful? And more importantly why do you want to
expose the imprecision in the mapping to the user space in the first
place?
--
Michal Hocko
SUSE Labs


\
 
 \ /
  Last update: 2015-10-27 14:01    [W:6.318 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site