From: Rik van Riel <riel@surriel.com>
To: Dave Chinner <dchinner@redhat.com>, Roman Gushchin <guro@fb.com>
Cc: "lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"mhocko@kernel.org" <mhocko@kernel.org>,
"guroan@gmail.com" <guroan@gmail.com>,
Kernel Team <Kernel-team@fb.com>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>
Subject: Re: [LSF/MM TOPIC] dying memory cgroups and slab reclaim issues
Date: Tue, 19 Feb 2019 12:31:10 -0500 [thread overview]
Message-ID: <7f66dd5242ab4d305f43d85de1a8e514fc47c492.camel@surriel.com> (raw)
In-Reply-To: <20190219020448.GY31397@rh>
[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]
On Tue, 2019-02-19 at 13:04 +1100, Dave Chinner wrote:
> On Tue, Feb 19, 2019 at 12:31:45AM +0000, Roman Gushchin wrote:
> > Sorry, resending with the fixed to/cc list. Please, ignore the
> > first letter.
>
> Please resend again with linux-fsdevel on the cc list, because this
> isn't a MM topic given the regressions from the shrinker patches
> have all been on the filesystem side of the shrinkers....
It looks like there are two separate things going on here.
The first are an MM issues, one of potentially leaking memory
by not scanning slabs with few items on them, and having
such slabs stay around forever after the cgroup they were
created for has disappeared, and the other of various other
bugs with shrinker invocation behavior (like the nr_deferred
fixes you posted a patch for). I believe these are MM topics.
The second is the filesystem (and maybe other) shrinker
functions' behavior being somewhat fragile and depending
on closely on current MM behavior, potentially up to
and including MM bugs.
The lack of a contract between the MM and the shrinker
callbacks is a recurring issue, and something we may
want to discuss in a joint session.
Some reflections on the shrinker/MM interaction:
- Since all memory (in a zone) could potentially be in
shrinker pools, shrinkers MUST eventually free some
memory.
- Shrinkers should not block kswapd from making progress.
If kswapd got stuck in NFS inode writeback, and ended up
not being able to free clean pages to receive network
packets, that might cause a deadlock.
- The MM should be able to deal with shrinkers doing
nothing at this call, but having some work pending
(eg. waiting on IO completion), without getting a false
OOM kill. How can we do this best?
- Related to the above: stalling in the shrinker code is
unpredictable, and can take an arbitrarily long amount
of time. Is there a better way we can make reclaimers
wait for in-flight work to be completed?
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-02-19 17:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 0:31 Roman Gushchin
2019-02-19 2:04 ` Dave Chinner
2019-02-19 17:31 ` Rik van Riel [this message]
2019-02-19 17:38 ` Michal Hocko
2019-02-19 23:26 ` Dave Chinner
2019-02-20 2:06 ` Rik van Riel
2019-02-20 4:33 ` Dave Chinner
2019-02-20 5:31 ` Roman Gushchin
2019-02-20 17:00 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2019-02-19 7:13 Roman Gushchin
2019-02-20 2:47 ` Dave Chinner
2019-02-20 5:50 ` Dave Chinner
2019-02-20 7:27 ` Dave Chinner
2019-02-20 16:20 ` Johannes Weiner
2019-02-21 22:46 ` Roman Gushchin
2019-02-22 1:48 ` Rik van Riel
2019-02-22 1:57 ` Roman Gushchin
2019-02-28 20:30 ` Roman Gushchin
2019-02-28 21:30 ` Dave Chinner
2019-02-28 22:29 ` Roman Gushchin
2019-02-18 23:53 Roman Gushchin
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=7f66dd5242ab4d305f43d85de1a8e514fc47c492.camel@surriel.com \
--to=riel@surriel.com \
--cc=Kernel-team@fb.com \
--cc=dchinner@redhat.com \
--cc=guro@fb.com \
--cc=guroan@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@kernel.org \
/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