All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: linux-mm@kvack.org
Cc: drjones@redhat.com, david@redhat.com, bhe@redhat.com,
	hannes@cmpxchg.org, guro@fb.com
Subject: [RFC PATCH] mm/vmscan: Don't round up scan size for online memory cgroup
Date: Mon, 10 Feb 2020 23:14:45 +1100	[thread overview]
Message-ID: <20200210121445.711819-1-gshan@redhat.com> (raw)

commit 68600f623d69 ("mm: don't miss the last page because of round-off
error") makes the scan size round up to @denominator regardless of the
memory cgroup's state, online or offline. This affects the overall
reclaiming behavior: The corresponding LRU list is eligible for reclaiming
only when its size logically right shifted by @sc->priority is bigger than
zero in the former formula (non-roundup one). For example, the inactive
anonymous LRU list should have at least 0x4000 pages to be eligible for
reclaiming when we have 60/12 for swappiness/priority and without taking
scan/rotation ratio into account. After the roundup is applied, the
inactive anonymous LRU list becomes eligible for reclaiming when its
size is bigger than or equal to 0x1000 in the same condition.

    (0x4000 >> 12) * 60 / (60 + 140 + 1) = 1
    ((0x1000 >> 12) * 60) + 200) / (60 + 140 + 1) = 1

aarch64 has 512MB huge page size when the base page size is 64KB. The
memory cgroup that has a huge page is always eligible for reclaiming in
that case. The reclaiming is likely to stop after the huge page is
reclaimed, meaing the subsequent @sc->priority and memory cgroups will be
skipped. It changes the overall reclaiming behavior. This fixes the issue
by applying the roundup to offlined memory cgroups only, to give more
preference to reclaim memory from offlined memory cgroup. It sounds
reasonable as those memory is likely to be useless.

The issue was found by starting up 8 VMs on a Ampere Mustang machine,
which has 8 CPUs and 16 GB memory. Each VM is given with 2 vCPUs and 2GB
memory. 784MB swap space is consumed after these 8 VMs are completely up.
Note that KSM is disable while THP is enabled in the testing. With this
applied, the consumed swap space decreased to 60MB.

         total        used        free      shared  buff/cache   available
Mem:     16196       10065        2049          16        4081        3749
Swap:     8175         784        7391
         total        used        free      shared  buff/cache   available
Mem:     16196       11324        3656          24        1215        2936
Swap:     8175          60        8115

Fixes: 68600f623d69 ("mm: don't miss the last page because of round-off error")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 mm/vmscan.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c05eb9efec07..876370565455 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2415,10 +2415,13 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
 			/*
 			 * 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.
+			 * Make sure we don't miss the last page on
+			 * the offlined memory cgroups because of a
+			 * round-off error.
 			 */
-			scan = DIV64_U64_ROUND_UP(scan * fraction[file],
+			scan = mem_cgroup_online(memcg) ?
+			       div64_u64(scan * fraction[file], denominator) :
+			       DIV64_U64_ROUND_UP(scan * fraction[file],
 						  denominator);
 			break;
 		case SCAN_FILE:
-- 
2.23.0



             reply	other threads:[~2020-02-10 12:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 12:14 Gavin Shan [this message]
2020-02-10 16:17 ` [RFC PATCH] mm/vmscan: Don't round up scan size for online memory cgroup Roman Gushchin
2020-02-10 23:55   ` Gavin Shan
2020-02-11  1:31     ` Roman Gushchin
2020-02-11  2:17       ` Gavin Shan
2020-02-11  3:03         ` Yang Shi
2020-02-12  2:38           ` Gavin Shan
2020-02-11 14:42         ` 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=20200210121445.711819-1-gshan@redhat.com \
    --to=gshan@redhat.com \
    --cc=bhe@redhat.com \
    --cc=david@redhat.com \
    --cc=drjones@redhat.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.