22 Aug
2022
22 Aug
'22
11:20 p.m.
On Mon, Aug 22, 2022 at 5:16 PM Andrew Morton akpm@linux-foundation.org wrote:
On Mon, 22 Aug 2022 16:59:29 -0600 Yu Zhao yuzhao@google.com wrote:
@@ -4109,7 +4109,7 @@ static int walk_pud_range(p4d_t *p4d, unsigned long start, unsigned long end,
walk_pmd_range(&val, addr, next, args);
if (mm_is_oom_victim(args->mm))
if (test_bit(MMF_OOM_REAP_QUEUED, &args->mm->flags)) return 1; /* a racy check to curtail the waiting time */Oh. Why? What does this change do?
The MMF_OOM_REAP_QUEUED flag is similar to the deleted MMF_OOM_VICTIM flag, but it's set at a later stage during an OOM kill.
When either is set, the OOM reaper is probably already freeing the memory of this mm_struct, or at least it's going to. So there is no need to dwell on it in the reclaim path, hence not about correctness.
Thanks. That sounds worthy of some code comments?
Will do. Thanks.