From: Sasha Levin <sashal@kernel.org>
To: akpm@linux-foundation.org
Cc: dairinin@gmail.com, guro@fb.com, mhocko@kernel.org,
mm-commits@vger.kernel.org, rdunlap@infradead.org,
riel@surriel.com, stable@vger.kernel.org,
torvalds@linux-foundation.org
Subject: Re: [patch 07/18] mm: don't reclaim inodes with many attached pages
Date: Fri, 16 Nov 2018 18:42:54 -0500 [thread overview]
Message-ID: <20181116234254.GK1706@sasha-vm> (raw)
In-Reply-To: <20181116230818.7gDYc8ifK%akpm@linux-foundation.org>
On Fri, Nov 16, 2018 at 03:08:18PM -0800, akpm@linux-foundation.org wrote:
>From: Roman Gushchin <guro@fb.com>
>Subject: mm: don't reclaim inodes with many attached pages
>
>Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs with
>a relatively small number of objects") leads to a regression on his setup:
>periodically the majority of the pagecache is evicted without an obvious
>reason, while before the change the amount of free memory was balancing
>around the watermark.
>
>The reason behind is that the mentioned above change created some minimal
>background pressure on the inode cache. The problem is that if an inode
>is considered to be reclaimed, all belonging pagecache page are stripped,
>no matter how many of them are there. So, if a huge multi-gigabyte file
>is cached in the memory, and the goal is to reclaim only few slab objects
>(unused inodes), we still can eventually evict all gigabytes of the
>pagecache at once.
>
>The workload described by Spock has few large non-mapped files in the
>pagecache, so it's especially noticeable.
>
>To solve the problem let's postpone the reclaim of inodes, which have more
>than 1 attached page. Let's wait until the pagecache pages will be
>evicted naturally by scanning the corresponding LRU lists, and only then
>reclaim the inode structure.
>
>Link: http://lkml.kernel.org/r/20181023164302.20436-1-guro@fb.com
>Signed-off-by: Roman Gushchin <guro@fb.com>
>Reported-by: Spock <dairinin@gmail.com>
>Tested-by: Spock <dairinin@gmail.com>
>Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
>Cc: Michal Hocko <mhocko@kernel.org>
>Cc: Rik van Riel <riel@surriel.com>
>Cc: Randy Dunlap <rdunlap@infradead.org>
>Cc: <stable@vger.kernel.org> [4.19.x]
>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Should I grab the other 6 patches in this "series"? (see Roman's
comments here: https://www.spinics.net/lists/stable/msg265152.html).
None of those is tagged for stable.
--
Thanks,
Sasha
prev parent reply other threads:[~2018-11-17 9:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 23:08 [patch 07/18] mm: don't reclaim inodes with many attached pages akpm
2018-11-16 23:42 ` Sasha Levin [this message]
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=20181116234254.GK1706@sasha-vm \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dairinin@gmail.com \
--cc=guro@fb.com \
--cc=mhocko@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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