From: Hasan Al Maruf <hasan3050@gmail.com>
To: dave.hansen@linux.intel.com, ying.huang@intel.com,
yang.shi@linux.alibaba.com, mgorman@techsingularity.net,
riel@surriel.com, hannes@cmpxchg.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH 5/5] active LRU-based promotion to avoid ping-pong
Date: Wed, 24 Nov 2021 13:58:30 -0500 [thread overview]
Message-ID: <80a0cfd545a01ce0470a727cb961a5e0a1532d48.1637778851.git.hasanalmaruf@fb.com> (raw)
In-Reply-To: <cover.1637778851.git.hasanalmaruf@fb.com>
Whenever a remote hint-fault happens on a page, the default NUMA
balancing promotes the page without checking its state. As a result,
cold pages with very infrequent accesses, can still be the promotion
candidates. Once promoted to the local node, these type of pages may
shortly become the demotion candidate if the toptier nodes are always
under pressure. Thus, promotion traffics generated from infrequently
accessed pages can easily fill up the toptier node's reclaimed free
spaces and eventually generate a higher demotion traffic for the non-
toptier node. This demotion-promotion ping-pong causes unnecessary
traffic over the memory nodes and can negatively impact on the
performance of memory bound applications.
To solve this ping-pong issue, instead of instant promotion, we check
a page's age through its position in the LRU list. If the faulted page
is in inactive LRU, then we don't instantly consider the page as the
promotion candidate as it might be an infrequently accessed pages. We
only consider the faulted pages that are in the active LRUs (either
of anon or file active LRU) as the promotion candidate. This approach
significantly reduce the promotion traffic and always maintain a
satisfactory amount of free memory on the toptier node to support both
new allocations and promotion from non-tortier nodes.
Signed-off-by: Hasan Al Maruf <hasanalmaruf@fb.com>
---
mm/memory.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 314fe3b2f462..1c76f074784a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4202,6 +4202,19 @@ static vm_fault_t do_numa_page(struct vm_fault *vmf)
last_cpupid = page_cpupid_last(page);
page_nid = page_to_nid(page);
+
+ /* Only migrate pages that are active on non-toptier node */
+ if (numa_promotion_tiered_enabled &&
+ !node_is_toptier(page_nid) &&
+ !PageActive(page)) {
+ count_vm_numa_event(NUMA_HINT_FAULTS);
+ if (page_nid == numa_node_id())
+ count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL);
+ mark_page_accessed(page);
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ goto out;
+ }
+
target_nid = numa_migrate_prep(page, vma, vmf->address, page_nid,
&flags);
pte_unmap_unlock(vmf->pte, vmf->ptl);
--
2.30.2
next prev parent reply other threads:[~2021-11-24 19:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 18:58 [PATCH 0/5] Transparent Page Placement for Tiered-Memory Hasan Al Maruf
2021-11-24 18:58 ` [PATCH 1/5] Promotion and demotion related statistics Hasan Al Maruf
2021-11-24 18:58 ` [PATCH 2/5] NUMA balancing for tiered-memory system Hasan Al Maruf
2021-11-24 18:58 ` [PATCH 3/5] Decouple reclaim and allocation for toptier nodes Hasan Al Maruf
2021-11-24 18:58 ` [PATCH 4/5] Reclaim to satisfy WMARK_DEMOTE on " Hasan Al Maruf
2021-11-24 18:58 ` Hasan Al Maruf [this message]
2021-11-25 1:23 ` [PATCH 0/5] Transparent Page Placement for Tiered-Memory Huang, Ying
2021-11-30 0:28 ` Hasan Al Maruf
2021-11-30 0:36 ` Hasan Al Maruf
2021-11-30 1:29 ` Huang, Ying
2021-11-30 4:49 ` Hasan Al Maruf
2024-07-01 15:28 ` luzhixing12345
2024-07-01 15:42 ` ask for commit hash luzhixing12345
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=80a0cfd545a01ce0470a727cb961a5e0a1532d48.1637778851.git.hasanalmaruf@fb.com \
--to=hasan3050@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@surriel.com \
--cc=yang.shi@linux.alibaba.com \
--cc=ying.huang@intel.com \
/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