Re: [PATCH] mm/oom_kill, proc: replace magic number 1000 with OOM_SCORE_ADJ_MAX
Ye Liu <[email protected]>
| Newsgroups | org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kvack.linux-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