From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org
Cc: surenb@google.com, akpm@linux-foundation.org, hannes@cmpxchg.org,
hillf.zj@alibaba-inc.com, minchan@kernel.org,
mgorman@techsingularity.net, ying.huang@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
timmurray@google.com, tkjos@google.com
Subject: Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending
Date: Fri, 8 Dec 2017 23:03:23 +0900 [thread overview]
Message-ID: <201712082303.DDG90166.FOLSHOOFVQJMtF@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20171208114806.GU20234@dhcp22.suse.cz>
Michal Hocko wrote:
> On Fri 08-12-17 20:36:16, Tetsuo Handa wrote:
> > On 2017/12/08 17:22, Michal Hocko wrote:
> > > On Thu 07-12-17 17:23:05, Suren Baghdasaryan wrote:
> > >> Slab shrinkers can be quite time consuming and when signal
> > >> is pending they can delay handling of the signal. If fatal
> > >> signal is pending there is no point in shrinking that process
> > >> since it will be killed anyway.
> > >
> > > The thing is that we are _not_ shrinking _that_ process. We are
> > > shrinking globally shared objects and the fact that the memory pressure
> > > is so large that the kswapd doesn't keep pace with it means that we have
> > > to throttle all allocation sites by doing this direct reclaim. I agree
> > > that expediting killed task is a good thing in general because such a
> > > process should free at least some memory.
> >
> > But doesn't doing direct reclaim mean that allocation request of already
> > fatal_signal_pending() threads will not succeed unless some memory is
> > reclaimed (or selected as an OOM victim)? Won't it just spin the "too
> > small to fail" retry loop at full speed in the worst case?
>
> Well, normally kswapd would do the work on the background. But this
> would have to be carefully evaluated. That is why I've said "expedite"
> rather than skip.
Relying on kswapd is a bad assumption, for kswapd can be blocked on e.g. fs
locks waiting for somebody else to reclaim memory.
>
> > >> This change checks for pending
> > >> fatal signals inside shrink_slab loop and if one is detected
> > >> terminates this loop early.
> > >
> > > This changelog doesn't really address my previous review feedback, I am
> > > afraid. You should mention more details about problems you are seeing
> > > and what causes them. If we have a shrinker which takes considerable
> > > amount of time them we should be addressing that. If that is not
> > > possible then it should be documented at least.
> >
> > Unfortunately, it is possible to be get blocked inside shrink_slab() for so long
> > like an example from http://lkml.kernel.org/r/1512705038.7843.6.camel@gmail.com .
>
> As I've said any excessive shrinker should definitely be evaluated.
The cause of stall inside shrink_slab() can be memory pressure itself.
There would be no problem if kswapd is sufficient (i.e. direct reclaim is
not needed). But there are many problems if direct reclaim is needed.
I agree that making waits/loops killable is generally good. But be sure to be
prepared for the worst case. For example, start __GFP_KILLABLE from "best effort"
basis (i.e. no guarantee that the allocating thread will leave the page allocator
slowpath immediately) and check for fatal_signal_pending() only if
__GFP_KILLABLE is set. That is,
+ /*
+ * We are about to die and free our memory.
+ * Stop shrinking which might delay signal handling.
+ */
+ if (unlikely((gfp_mask & __GFP_KILLABLE) && fatal_signal_pending(current)))
+ break;
at shrink_slab() etc. and
+ if ((gfp_mask & __GFP_KILLABLE) && fatal_signal_pending(current))
+ goto nopage;
at __alloc_pages_slowpath().
next prev parent reply other threads:[~2017-12-08 14:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 1:23 [PATCH v2] mm: terminate shrink_slab loop if signal is pending Suren Baghdasaryan
2017-12-08 8:22 ` Michal Hocko
2017-12-08 11:36 ` Tetsuo Handa
2017-12-08 11:48 ` Michal Hocko
2017-12-08 14:03 ` Tetsuo Handa [this message]
2017-12-08 18:06 ` Suren Baghdasaryan
2017-12-09 8:08 ` Tetsuo Handa
2017-12-10 10:17 ` Michal Hocko
2017-12-11 21:05 ` Suren Baghdasaryan
2017-12-10 10:13 ` Michal Hocko
2017-12-10 11:37 ` Tetsuo Handa
2017-12-11 21:12 ` Suren Baghdasaryan
2017-12-08 21:02 ` David Rientjes
2017-12-09 3:16 ` Suren Baghdasaryan
2017-12-09 12:44 ` Tetsuo Handa
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=201712082303.DDG90166.FOLSHOOFVQJMtF@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=surenb@google.com \
--cc=timmurray@google.com \
--cc=tkjos@google.com \
--cc=ying.huang@intel.com \
/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).