Re: [PATCH] mm/oom_kill, proc: replace magic number 1000 with OOM_SCORE_ADJ_MAX

[Michal Hocko <mhocko@suse.com>]

On Wed 19-08-26 11:15:52, Ye Liu wrote:
> 
> 
> 在 2026/8/18 09:04, Song Hu 写道:
> > On 2026/8/11 11:36, Ye Liu wrote:
> >> --- a/mm/oom_kill.c
> >> +++ b/mm/oom_kill.c
> >> @@ -230,7 +230,7 @@ long oom_badness(struct task_struct *p, unsigned long totalpages)
> >>  	task_unlock(p);
> >>
> >>  	/* Normalize to oom_score_adj units */
> >> -	adj *= totalpages / 1000;
> >> +	adj *= totalpages / OOM_SCORE_ADJ_MAX;
> > 
> > One thing this line hides: for a memcg OOM, totalpages is
> > mem_cgroup_get_max(), which can be below 1000 pages when the
> > container limit is under 4M.  The division then yields 0, the whole
> > oom_score_adj contribution goes away, and a task protected with
> > -997 scores the same as a best-effort task with 1000.  The -1000
> > exemption is checked separately above and still works.
> > 
> > DIV_ROUND_UP(totalpages, OOM_SCORE_ADJ_MAX) would preserve the adj
> > weighting for small limits and change nothing meaningful for large
> > ones.  This is an edge case, so probably fine to leave as is -
> > noting it here since the line is being touched anyway.
> 
> Good catch. Yes, the truncation for totalpages < 1000 is real, 
> but as you noted, it's an existing edge case. I'll keep this patch 
> as a mechanical replacement and won't address it here. Out of curiosity,
> are sub-4MB memcg limits actually used in practice? 

I have seen containers as small as 20MB and they were suffering from
quite some problems - e.g. charge caching on different leyers. I would
generally discourage people from running containers that small unless
they exactly know what they are doing.
-- 
Michal Hocko
SUSE Labs