Messages in this thread | | | Date | Tue, 27 Oct 2015 13:37:04 +0100 | From | Michal Hocko <> | Subject | Re: [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
| |