From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: linux-mm@kvack.org, akpm@linux-foundation.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Mel Gorman <mgorman@suse.de>, Yu Zhao <yuzhao@google.com>,
Wei Xu <weixugc@google.com>, Guru Anbalagane <gurua@google.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Subject: [RFC PATCH v1 3/7] mm: multi-gen LRU: avoid using generation stored in page flags for generation
Date: Sun, 2 Apr 2023 16:12:36 +0530 [thread overview]
Message-ID: <20230402104240.1734931-4-aneesh.kumar@linux.ibm.com> (raw)
In-Reply-To: <20230402104240.1734931-1-aneesh.kumar@linux.ibm.com>
Some architectures can handle different methods for determining page
access count. In such case, we may not really need to use page flags
for tracking generation. We can possibly derive generation directly
from arch-supported access count values. Hence avoid using page flags
to store generation in that case.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
include/linux/page_aging.h | 26 ++++++++++++++++++++++++++
mm/rmap.c | 4 +++-
mm/vmscan.c | 34 +++++++++++++++++++++++++---------
3 files changed, 54 insertions(+), 10 deletions(-)
create mode 100644 include/linux/page_aging.h
diff --git a/include/linux/page_aging.h b/include/linux/page_aging.h
new file mode 100644
index 000000000000..ab77f4578916
--- /dev/null
+++ b/include/linux/page_aging.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _LINUX_PAGE_AGING_H
+#define _LINUX_PAGE_AGING_H
+
+#ifndef arch_supports_page_access_count
+static inline bool arch_supports_page_access_count(void)
+{
+ return false;
+}
+#endif
+
+#ifdef CONFIG_LRU_GEN
+#ifndef arch_get_lru_gen_seq
+static inline unsigned long arch_get_lru_gen_seq(struct lruvec *lruvec, struct folio *folio)
+{
+ int type = folio_is_file_lru(folio);
+
+ return lruvec->lrugen.min_seq[type];
+}
+#endif
+#endif /* CONFIG_LRU_GEN */
+
+#endif
+
+
diff --git a/mm/rmap.c b/mm/rmap.c
index b616870a09be..1ef3cb8119d5 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -74,6 +74,7 @@
#include <linux/memremap.h>
#include <linux/userfaultfd_k.h>
#include <linux/mm_inline.h>
+#include <linux/page_aging.h>
#include <asm/tlbflush.h>
@@ -825,7 +826,8 @@ static bool folio_referenced_one(struct folio *folio,
if (pvmw.pte) {
if (lru_gen_enabled() && pte_young(*pvmw.pte) &&
!(vma->vm_flags & (VM_SEQ_READ | VM_RAND_READ))) {
- lru_gen_look_around(&pvmw);
+ if (!arch_supports_page_access_count())
+ lru_gen_look_around(&pvmw);
referenced++;
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f92b689af2a5..518d1482f6ab 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -62,6 +62,7 @@
#include <linux/swapops.h>
#include <linux/balloon_compaction.h>
#include <linux/sched/sysctl.h>
+#include <linux/page_aging.h>
#include "internal.h"
#include "swap.h"
@@ -4934,7 +4935,7 @@ void lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
{
bool success;
- int gen = folio_lru_gen(folio);
+ int gen;
int type = folio_is_file_lru(folio);
int zone = folio_zonenum(folio);
int delta = folio_nr_pages(folio);
@@ -4942,7 +4943,6 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
int tier = lru_tier_from_refs(refs);
struct lru_gen_struct *lrugen = &lruvec->lrugen;
- VM_WARN_ON_ONCE_FOLIO(gen >= MAX_NR_GENS, folio);
/* unevictable */
if (!folio_evictable(folio)) {
@@ -4963,8 +4963,14 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
return true;
}
- /* promoted */
+ if (!arch_supports_page_access_count()) {
+ gen = folio_lru_gen(folio);
+ VM_WARN_ON_ONCE_FOLIO(gen >= MAX_NR_GENS, folio);
+ } else
+ gen = lru_gen_from_seq(arch_get_lru_gen_seq(lruvec, folio));
+
if (gen != lru_gen_from_seq(lrugen->min_seq[type])) {
+ /* promote the folio */
list_move(&folio->lru, &lrugen->lists[gen][type][zone]);
return true;
}
@@ -5464,12 +5470,22 @@ bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio, bool reclaimi
*/
if (folio_test_active(folio))
seq = lrugen->max_seq;
- else if ((type == LRU_GEN_ANON && !folio_test_swapcache(folio)) ||
- (folio_test_reclaim(folio) &&
- (folio_test_dirty(folio) || folio_test_writeback(folio))))
- seq = lrugen->min_seq[type] + 1;
- else
- seq = lrugen->min_seq[type];
+ else {
+ /*
+ * For a non active folio use the arch based
+ * aging details to derive the MGLRU generation.
+ */
+ seq = arch_get_lru_gen_seq(lruvec, folio);
+
+ if (seq == lrugen->min_seq[type]) {
+ if ((type == LRU_GEN_ANON &&
+ !folio_test_swapcache(folio)) ||
+ (folio_test_reclaim(folio) &&
+ (folio_test_dirty(folio) ||
+ folio_test_writeback(folio))))
+ seq = lrugen->min_seq[type] + 1;
+ }
+ }
gen = lru_gen_from_seq(seq);
flags = (gen + 1UL) << LRU_GEN_PGOFF;
--
2.39.2
next prev parent reply other threads:[~2023-04-02 10:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-02 10:42 [RFC PATCH v1 0/7] Support arch-specific page aging mechanism Aneesh Kumar K.V
2023-04-02 10:42 ` [RFC PATCH v1 1/7] mm: Move some code around so that next patch is simpler Aneesh Kumar K.V
2023-04-02 10:42 ` [RFC PATCH v1 2/7] mm: Don't build multi-gen LRU page table walk code on architecture not supported Aneesh Kumar K.V
2023-04-02 10:42 ` Aneesh Kumar K.V [this message]
2023-04-02 10:42 ` [RFC PATCH v1 4/7] mm: multi-gen LRU: support different page aging mechanism Aneesh Kumar K.V
2023-04-02 10:42 ` [RFC PATCH v1 5/7] powerpc/mm: Add page access count support Aneesh Kumar K.V
2023-04-02 10:42 ` [RFC PATCH v1 6/7] powerpc/mm: Clear page access count on allocation Aneesh Kumar K.V
2023-04-02 10:42 ` [RFC PATCH v1 7/7] mm: multi-gen LRU: Shrink folio list without checking for page table reference Aneesh Kumar K.V
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=20230402104240.1734931-4-aneesh.kumar@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=gurua@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.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;
as well as URLs for NNTP newsgroup(s).