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

Ye Liu <[email protected]>
Newsgroups gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>

在 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? 

-- 
Thanks,
Ye Liu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.