LKML Archive on lore.kernel.org
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: Mon, 16 Mar 2020 10:32:36 +0100 [thread overview]
Message-ID: <20200316093236.GF11482@dhcp22.suse.cz> (raw)
In-Reply-To: <20200312201624.GD23944@dhcp22.suse.cz>
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
next prev parent reply other threads:[~2020-03-16 9:32 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
2020-03-16 9:32 ` Michal Hocko [this message]
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=20200316093236.GF11482@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).