From: Roman Gushchin <guro@fb.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
Roman Gushchin <guro@fb.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>, Tejun Heo <tj@kernel.org>,
Rik van Riel <riel@surriel.com>,
Konstantin Khlebnikov <koct9i@gmail.com>
Subject: [PATCH RFC] mm: don't miss the last page because of round-off error
Date: Fri, 17 Aug 2018 16:18:34 -0700 [thread overview]
Message-ID: <20180817231834.15959-1-guro@fb.com> (raw)
I've noticed, that dying memory cgroups are often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.
My investigation showed that the problem is caused by
applying the LRU pressure balancing math:
scan = div64_u64(scan * fraction[lru], denominator),
where
denominator = fraction[anon] + fraction[file] + 1.
Because fraction[lru] is always less than denominator,
if the initial scan size is 1, the result is always 0.
This means the last page is not scanned and has
no chances to be reclaimed.
Fix this by skipping the balancing logic if the initial
scan count is 1.
In practice this change significantly improves the speed
of dying cgroups reclaim.
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
---
mm/vmscan.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f86f288..f85c5ec01886 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2287,9 +2287,12 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
/*
* Scan types proportional to swappiness and
* their relative recent reclaim efficiency.
+ * Make sure we don't miss the last page
+ * because of a round-off error.
*/
- scan = div64_u64(scan * fraction[file],
- denominator);
+ if (scan > 1)
+ scan = div64_u64(scan * fraction[file],
+ denominator);
break;
case SCAN_FILE:
case SCAN_ANON:
--
2.17.1
next reply other threads:[~2018-08-17 23:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 23:18 Roman Gushchin [this message]
2018-08-18 1:22 ` Matthew Wilcox
2018-08-20 17:19 ` Roman Gushchin
2018-08-21 5:11 ` Konstantin Khlebnikov
2018-08-21 13:35 ` Matthew Wilcox
2018-08-21 17:15 ` Johannes Weiner
2018-08-22 6:01 ` Konstantin Khlebnikov
2018-08-22 17:50 ` 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=20180817231834.15959-1-guro@fb.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=tj@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