From: Andrew Morton <akpm@linux-foundation.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Dave Chinner <david@fromorbit.com>,
Al Viro <viro@zeniv.linux.org.uk>, Linux MM <linux-mm@kvack.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/4] memcg, inode: protect page cache from freeing inode
Date: Tue, 17 Dec 2019 17:37:35 -0800 [thread overview]
Message-ID: <20191217173735.e8ae519f4930b31f99f71619@linux-foundation.org> (raw)
In-Reply-To: <20191217165422.GA213613@cmpxchg.org>
On Tue, 17 Dec 2019 11:54:22 -0500 Johannes Weiner <hannes@cmpxchg.org> wrote:
> I've carried the below patch in my private tree for testing cache
> aging decisions that the shrinker interfered with. (It would be nicer
> if page cache pages could pin the inode of course, but reclaim cannot
> easily participate in the inode refcounting scheme.)
>
> ...
>
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -753,7 +753,13 @@ static enum lru_status inode_lru_isolate(struct list_head *item,
> return LRU_ROTATE;
> }
>
> - if (inode_has_buffers(inode) || inode->i_data.nrpages) {
> + /* Leave the pages to page reclaim */
> + if (inode->i_data.nrpages) {
> + spin_unlock(&inode->i_lock);
> + return LRU_ROTATE;
> + }
I guess that code should have been commented...
This code was originally added because on large highmem machines we
were seeing lowmem full of inodes which had one or more highmem pages
attached to them. Highmem was not under memory pressure so those
pagecache pages remained unreclaimed "for ever", thus pinning their
lowmem inode. The net result was exhaustion of lowmem.
I guess a #ifdef CONFIG_HIGHMEM would help, to preserve the old
behavior in that case. Although given the paucity of testing on large
highmem machines, the risk of divergent behavior over time is a
concern.
next prev parent reply other threads:[~2019-12-18 1:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 11:29 [PATCH 0/4] memcg, inode: protect page cache from freeing inode Yafang Shao
2019-12-17 11:29 ` [PATCH 1/4] mm, memcg: reduce size of struct mem_cgroup by using bit field Yafang Shao
2019-12-17 11:29 ` [PATCH 2/4] mm, memcg: introduce MEMCG_PROT_SKIP for memcg zero usage case Yafang Shao
2019-12-17 11:29 ` [PATCH 3/4] mm, memcg: reset memcg's memory.{min, low} for reclaiming itself Yafang Shao
2019-12-17 14:20 ` Chris Down
2019-12-18 1:13 ` Yafang Shao
2019-12-17 11:29 ` [PATCH 4/4] memcg, inode: protect page cache from freeing inode Yafang Shao
2019-12-18 2:21 ` Dave Chinner
2019-12-18 2:33 ` Yafang Shao
2019-12-18 17:53 ` Roman Gushchin
2019-12-19 1:45 ` Yafang Shao
2019-12-17 11:56 ` [PATCH 0/4] " Michal Hocko
2019-12-17 12:19 ` Yafang Shao
2019-12-17 16:54 ` Johannes Weiner
2019-12-18 1:17 ` Yafang Shao
2019-12-18 1:37 ` Andrew Morton [this message]
2019-12-18 1:51 ` Dave Chinner
2019-12-18 4:37 ` Johannes Weiner
2019-12-18 10:16 ` Dave Chinner
2019-12-18 21:38 ` Johannes Weiner
2019-12-19 2:04 ` Yafang Shao
2020-01-10 2:08 ` Dave Chinner
2019-12-18 17:27 ` 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=20191217173735.e8ae519f4930b31f99f71619@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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).