On Thu 12-03-20 21:16:27, Michal Hocko wrote: > On Thu 12-03-20 11:20:33, David Rientjes wrote: > > 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. > > In the context of UP and !PREEMPT this also includes IO flushers, > filesystems rely on workers and there are things I am very likely not > aware of. If you think this is vaague then feel free to reformulate. > All I really do care about is what the next paragraph is explaining. Btw. do you plan to send a patch with an updated changelog? > > > 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. > > > " > > > > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs
