Re: [PATCH memcg v3 2/3] mm, oom: do not trigger out_of_memory from the #PF
From: Vasily Averin <hidden>
Date: 2021-10-23 19:15:50
Also in:
linux-mm, lkml
On 23.10.2021 18:01, Tetsuo Handa wrote:
On 2021/10/23 22:20, Vasily Averin wrote:quoted
/* - * The pagefault handler calls here because it is out of memory, so kill a - * memory-hogging task. If oom_lock is held by somebody else, a parallel oom - * killing is already in progress so do nothing. + * The pagefault handler calls here because some allocation has failed. We have + * to take care of the memcg OOM here because this is the only safe context without + * any locks held but let the oom killer triggered from the allocation context care + * about the global OOM. */Excuse me for a stupid question. I consider if (!mutex_trylock(&oom_lock)) return; out_of_memory(&oc); mutex_unlock(&oom_lock); here as the last resort (safeguard) when neither __alloc_pages_may_oom() nor mem_cgroup_out_of_memory() can make progress. This patch says let the oom killer triggered from the allocation context care about the global OOM. but what if the OOM killer cannot be invoked from the allocation context? Is there a guarantee that all memory allocations which might result in VM_FAULT_OOM can invoke the OOM killer?
I don't think this question is stupid, since I asked it myself :) You can find this discussion here: https://lkml.org/lkml/2021/10/21/900 Let me quote it here too :> 1) VM_FAULT_OOM may be triggered w/o execution of out_of_memory() :> for exampel it can be caused by incorrect vm fault operations, :> (a) which can return this error without calling allocator at all. : :I would argue this to be a bug. How can that particular code tell :whether the system is OOM and the oom killer is the a reasonable measure :to take? : :> (b) or which can provide incorrect gfp flags and allocator can fail without execution of out_of_memory. : : I am not sure I can see any sensible scenario where pagefault oom killer : would be an appropriate fix for that. : :> (c) This may happen on stable/LTS kernels when successful allocation was failed by hit into limit of legacy memcg-kmem contoller. :> We'll drop it in upstream kernels, however how to handle it in old kenrels? : :Triggering the global oom killer for legacy kmem charge failure is :clearly wrong. Removing oom killer from #PF would fix that problem. I would note: (c) is not theoretical but real life problem, in this case allocation was failed without execution of OOM, however, it is in this case that execution out_of_memory() from pagefault_out_of_memory() leads to a disaster. Thank you, Vasily Averin