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 4/7] mm: multi-gen LRU: support different page aging mechanism
Date: Sun, 2 Apr 2023 16:12:37 +0530 [thread overview]
Message-ID: <20230402104240.1734931-5-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. We may want to do architecture-specific tasks
reclassifying generation temperature etc during aging for such
architecture. Add an arch hook to support that.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
include/linux/page_aging.h | 14 +++++++++++++-
mm/vmscan.c | 8 +++++++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/linux/page_aging.h b/include/linux/page_aging.h
index ab77f4578916..d7c63ce0d824 100644
--- a/include/linux/page_aging.h
+++ b/include/linux/page_aging.h
@@ -11,6 +11,10 @@ static inline bool arch_supports_page_access_count(void)
#endif
#ifdef CONFIG_LRU_GEN
+bool __try_to_inc_max_seq(struct lruvec *lruvec,
+ unsigned long max_seq, int scan_priority,
+ bool can_swap, bool force_scan);
+
#ifndef arch_get_lru_gen_seq
static inline unsigned long arch_get_lru_gen_seq(struct lruvec *lruvec, struct folio *folio)
{
@@ -19,8 +23,16 @@ static inline unsigned long arch_get_lru_gen_seq(struct lruvec *lruvec, struct f
return lruvec->lrugen.min_seq[type];
}
#endif
-#endif /* CONFIG_LRU_GEN */
+#ifndef arch_try_to_inc_max_seq
+static inline bool arch_try_to_inc_max_seq(struct lruvec *lruvec, unsigned long max_seq,
+ int scan_priority, bool can_swap, bool force_scan)
+{
+ return __try_to_inc_max_seq(lruvec, max_seq, scan_priority, can_swap, force_scan);
+}
+#endif
+
+#endif /* CONFIG_LRU_GEN */
#endif
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 518d1482f6ab..c8b98201f0b0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4536,7 +4536,13 @@ bool __try_to_inc_max_seq(struct lruvec *lruvec,
static bool try_to_inc_max_seq(struct lruvec *lruvec, unsigned long max_seq,
int scan_priority, bool can_swap, bool force_scan)
{
- return __try_to_inc_max_seq(lruvec, max_seq, scan_priority, can_swap, force_scan);
+ if (arch_supports_page_access_count())
+ return arch_try_to_inc_max_seq(lruvec, max_seq,
+ scan_priority, can_swap,
+ force_scan);
+ else
+ return __try_to_inc_max_seq(lruvec, max_seq,
+ scan_priority, can_swap, force_scan);
}
#endif
--
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 ` [RFC PATCH v1 3/7] mm: multi-gen LRU: avoid using generation stored in page flags for generation Aneesh Kumar K.V
2023-04-02 10:42 ` Aneesh Kumar K.V [this message]
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-5-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).