lkml.org 
[lkml]   [2020]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems
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.
> "
>

\
 
 \ /
  Last update: 2020-03-12 19:20    [W:0.594 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site