[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251218072543.5071-1-kdipendra88@gmail.com>
Date: Thu, 18 Dec 2025 07:25:41 +0000
From: Dipendra Khadka <kdipendra88@...il.com>
To: hannes@...xchg.org
Cc: akpm@...ux-foundation.org,
mhocko@...nel.org,
roman.gushchin@...ux.dev,
shakeel.butt@...ux.dev,
muchun.song@...ux.dev,
cgroups@...r.kernel.org,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/memcg: reorder retry checks for clarity in try_charge_memcg
Hi Johannes,
Thank you for the feedback. Let me clarify the scenario this patch addresses.
The task_is_dying() check in try_charge_memcg() identifies when the
CURRENT task (the caller) is the OOM victim - not when some other
process was killed.
Two scenarios:
1. Normal allocator triggers OOM:
- Process A allocates → triggers OOM
- Process B is killed (victim)
- Process A continues with reset retries - task_is_dying() = false for A
→ Unchanged by my patch
2. Victim tries to allocate:
- Process B (victim, TIF_MEMDIE set) tries to allocate
- task_is_dying() = true
- Current code: wastes retries on hopeless reclaims
- My patch: exits immediately
→ Optimization for this case
The victim has three safety mechanisms that make the retries unnecessary:
1. oom_reaper proactively frees its memory
2. __alloc_pages_slowpath() grants reserves via oom_reserves_allowed()
3. Critical allocations with __GFP_NOFAIL still reach force: label
The retry loop for a dying victim is futile because:
- Reclaim won't help (victim is being killed to free memory!)
- Victim will exit regardless
- Just wastes CPU cycles
Would you like me to provide evidence showing the unnecessary retries,
or run specific tests to verify the safety mechanisms are sufficient?
Best Regards,
Dipendra
Powered by blists - more mailing lists