On Thu, 12 Mar 2020, Michal Hocko wrote: > > I think the changelog clearly states that we need to guarantee that a > > reclaimer will yield the processor back to allow a victim to exit. This > > is where we make the guarantee. If it helps for the specific reason it > > triggered in my testing, we could add: > > > > "For example, mem_cgroup_protected() can prohibit reclaim and thus any > > yielding in page reclaim would not address the issue." > > I would suggest something like the following: > " > The reclaim path (including the OOM) relies on explicit scheduling > points to hand over execution to tasks which could help with the reclaim > process. Are there other examples where yielding in the reclaim path would "help with the reclaim process" other than oom victims? This sentence seems vague. > Currently it is mostly shrink_page_list which yields CPU for > each reclaimed page. This might be insuficient though in some > configurations. E.g. when a memcg OOM path is triggered in a hierarchy > which doesn't have any reclaimable memory because of memory reclaim > protection (MEMCG_PROT_MIN) then there is possible to trigger a soft > lockup during an out of memory situation on non preemptible kernels > <PUT YOUR SOFT LOCKUP SPLAT HERE> > > Fix this by adding a cond_resched up in the reclaim path and make sure > there is a yield point regardless of reclaimability of the target > hierarchy. > " >
