From: Andrew Morton <akpm@linux-foundation.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: dchinner@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org,
vdavydov.dev@gmail.com, guro@fb.com, viro@zeniv.linux.org.uk,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v4 0/3] protect page cache from freeing inode
Date: Sun, 23 Feb 2020 19:17:07 -0800 [thread overview]
Message-ID: <20200223191707.0a55e949fad943b04c2b65e7@linux-foundation.org> (raw)
In-Reply-To: <1582450294-18038-1-git-send-email-laoar.shao@gmail.com>
On Sun, 23 Feb 2020 04:31:31 -0500 Yafang Shao <laoar.shao@gmail.com> wrote:
> On my server there're some running MEMCGs protected by memory.{min, low},
> but I found the usage of these MEMCGs abruptly became very small, which
> were far less than the protect limit. It confused me and finally I
> found that was because of inode stealing.
> Once an inode is freed, all its belonging page caches will be dropped as
> well, no matter how may page caches it has. So if we intend to protect the
> page caches in a memcg, we must protect their host (the inode) first.
> Otherwise the memcg protection can be easily bypassed with freeing inode,
> especially if there're big files in this memcg.
> The inherent mismatch between memcg and inode is a trouble. One inode can
> be shared by different MEMCGs, but it is a very rare case. If an inode is
> shared, its belonging page caches may be charged to different MEMCGs.
> Currently there's no perfect solution to fix this kind of issue, but the
> inode majority-writer ownership switching can help it more or less.
What are the potential regression scenarios here? Presumably a large
number of inodes pinned by small amounts of pagecache, consuming memory
and CPU during list scanning. Anything else?
Have you considered constructing test cases to evaluate the impact of
such things?
next prev parent reply other threads:[~2020-02-24 3:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 9:31 Yafang Shao
2020-02-23 9:31 ` [PATCH v4 1/3] mm, list_lru: make memcg visible to lru walker isolation function Yafang Shao
2020-02-23 9:31 ` [PATCH v4 2/3] mm, shrinker: make memcg low reclaim " Yafang Shao
2020-02-23 9:31 ` [PATCH v4 3/3] inode: protect page cache from freeing inode Yafang Shao
2020-02-24 3:17 ` Andrew Morton [this message]
2020-02-26 14:16 ` [PATCH v4 0/3] " Yafang Shao
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=20200223191707.0a55e949fad943b04c2b65e7@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=guro@fb.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