linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems
Date: Thu, 12 Mar 2020 21:16:24 +0100	[thread overview]
Message-ID: <20200312201624.GD23944@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.21.2003121115480.158939@chino.kir.corp.google.com>

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.

> > 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


  reply	other threads:[~2020-03-12 20:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 21:39 [patch] mm, oom: prevent soft lockup on memcg oom for UP systems David Rientjes
2020-03-10 22:05 ` Tetsuo Handa
2020-03-10 22:55   ` David Rientjes
2020-03-11  9:34     ` Tetsuo Handa
2020-03-11 19:38       ` David Rientjes
2020-03-11 22:04         ` Tetsuo Handa
2020-03-11 22:14           ` David Rientjes
2020-03-12  0:12             ` Tetsuo Handa
2020-03-12 18:07               ` David Rientjes
2020-03-12 22:32                 ` Andrew Morton
2020-03-16  9:31                   ` Michal Hocko
2020-03-16 10:04                     ` Tetsuo Handa
2020-03-16 10:14                       ` Michal Hocko
2020-03-13  0:15                 ` Tetsuo Handa
2020-03-13 22:01                   ` David Rientjes
2020-03-13 23:15                     ` Tetsuo Handa
2020-03-13 23:32                       ` Tetsuo Handa
2020-03-16 23:59                         ` David Rientjes
2020-03-17  3:18                           ` Tetsuo Handa
2020-03-17  4:09                             ` David Rientjes
2020-03-18  0:55                               ` [patch v2] " David Rientjes
2020-03-18  9:42                                 ` Michal Hocko
2020-03-18 21:40                                   ` David Rientjes
2020-03-18 22:03                                     ` [patch v3] " David Rientjes
2020-03-19  7:09                                       ` Michal Hocko
2020-03-12  4:23             ` [patch] " Tetsuo Handa
2020-03-10 22:10 ` Michal Hocko
2020-03-10 23:02   ` David Rientjes
2020-03-11  8:27     ` Michal Hocko
2020-03-11 19:45       ` David Rientjes
2020-03-12  8:32         ` Michal Hocko
2020-03-12 18:20           ` David Rientjes
2020-03-12 20:16             ` Michal Hocko [this message]
2020-03-16  9:32               ` Michal Hocko
2020-03-11  0:18 ` Andrew Morton
2020-03-11  0:34   ` David Rientjes
2020-03-11  8:36   ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200312201624.GD23944@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).