From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: axelrasmussen@google.com
Cc: akpm@linux-foundation.org, baohua@kernel.org, kasong@tencent.com,
lance.yang@linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, liulei.rjpt@vivo.com, pfalcato@suse.de,
qi.zheng@linux.dev, shakeel.butt@linux.dev, surenb@google.com,
wangzicheng@honor.com, weixugc@google.com, will@kernel.org,
willy@infradead.org, xueyuan.chen21@gmail.com,
yuanchu@google.com
Subject: Re: [PATCH] mm/mglru: Use folio_mark_accessed to replace folio_set_active in PF
Date: Tue, 28 Apr 2026 09:35:20 +0800 [thread overview]
Message-ID: <20260428013520.47417-1-baohua@kernel.org> (raw)
In-Reply-To: <CAJHvVcjH+BS306KKOsFcVKkbmkj0aKXtfpuFy+SVYKE4PQmVQw@mail.gmail.com>
On Tue, Apr 28, 2026 at 2:23 AM Axel Rasmussen <axelrasmussen@google.com> wrote:
>
> For what it's worth, I agree with this change in principle.
>
> In production we set fault_around_bytes to 4096. That setting is
> surprisingly load-bearing (i.e. if I change it, even at a small
> experimental scale, I expect workloads to notice and complain). So I
> don't think I have an easy way to test this change under production
> workloads.
>
> Like Andrew said the workload in the commit message doesn't seem
> unreasonable, and the benefit is large.
>
> I guess the workload that would see a downside from this is one that
> heavily uses readahead pages but also generates many "one-time-use"
> pages instead of maintaining a "fixed" working set. Without activating
> the readahead pages, does it lose some of the readahead benefit
> because they are pushed out?
>
> About the Sashiko comments, the tier bits being cleared doesn't seem
> that problematic to me. However, the WORKINGSET_ACTIVATE counter issue
> seems worth fixing.
>
I am considering something more reasonable than simply
"fixing" the counter. Right now, MGLRU unconditionally
treats PF folios as WORKINGSET_ACTIVATE_BASE and neglects
other folios entirely. I am thinking of a better approach
that detects true recency. In the active/inactive case,
this is refault_distance < workingset_size.
In MGLRU, we might detect whether reclamation occurred
within the most recent one or two generations. I am
queuing the following for testing:
diff --git a/mm/workingset.c b/mm/workingset.c
index 07e6836d0502..8b552b3d7e37 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -271,10 +271,11 @@ static void *lru_gen_eviction(struct folio *folio)
* Fills in @lruvec, @token, @workingset with the values unpacked from shadow.
*/
static bool lru_gen_test_recent(void *shadow, struct lruvec **lruvec,
- unsigned long *token, bool *workingset, bool file)
+ unsigned long *token, bool *workingset, bool file,
+ unsigned long *gen_distance)
{
int memcg_id;
- unsigned long max_seq;
+ unsigned long max_seq, distance;
struct mem_cgroup *memcg;
struct pglist_data *pgdat;
@@ -286,7 +287,10 @@ static bool lru_gen_test_recent(void *shadow, struct lruvec **lruvec,
max_seq = READ_ONCE((*lruvec)->lrugen.max_seq);
max_seq &= (file ? EVICTION_MASK : EVICTION_MASK_ANON) >> LRU_REFS_WIDTH;
- return abs_diff(max_seq, *token >> LRU_REFS_WIDTH) < MAX_NR_GENS;
+ distance = abs_diff(max_seq, *token >> LRU_REFS_WIDTH);
+ if (gen_distance)
+ *gen_distance = distance;
+ return distance < MAX_NR_GENS;
}
static void lru_gen_refault(struct folio *folio, void *shadow)
@@ -294,7 +298,7 @@ static void lru_gen_refault(struct folio *folio, void *shadow)
bool recent;
int hist, tier, refs;
bool workingset;
- unsigned long token;
+ unsigned long token, distance;
struct lruvec *lruvec;
struct lru_gen_folio *lrugen;
int type = folio_is_file_lru(folio);
@@ -302,7 +306,8 @@ static void lru_gen_refault(struct folio *folio, void *shadow)
rcu_read_lock();
- recent = lru_gen_test_recent(shadow, &lruvec, &token, &workingset, type);
+ recent = lru_gen_test_recent(shadow, &lruvec, &token, &workingset, type,
+ &distance);
if (lruvec != folio_lruvec(folio))
goto unlock;
@@ -319,9 +324,11 @@ static void lru_gen_refault(struct folio *folio, void *shadow)
atomic_long_add(delta, &lrugen->refaulted[hist][type][tier]);
- /* see folio_add_lru() where folio_set_active() will be called */
- if (lru_gen_in_fault())
+ /* If the folio was reclaimed very recently. */
+ if (distance <= MIN_LRU_GENS) {
+ folio_set_active(folio);
mod_lruvec_state(lruvec, WORKINGSET_ACTIVATE_BASE + type, delta);
+ }
if (workingset) {
folio_set_workingset(folio);
@@ -442,7 +449,7 @@ bool workingset_test_recent(void *shadow, bool file, bool *workingset,
rcu_read_lock();
recent = lru_gen_test_recent(shadow, &eviction_lruvec, &eviction,
- workingset, file);
+ workingset, file, NULL);
rcu_read_unlock();
return recent;
}
next prev parent reply other threads:[~2026-04-28 1:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 12:02 [PATCH] mm/mglru: Use folio_mark_accessed to replace folio_set_active in PF Barry Song (Xiaomi)
2026-04-24 11:53 ` Andrew Morton
2026-04-28 5:40 ` Barry Song
2026-04-24 14:10 ` Andrew Morton
2026-04-24 15:19 ` Pedro Falcato
2026-04-26 4:35 ` Barry Song
2026-04-27 14:46 ` Pedro Falcato
2026-04-27 18:22 ` Axel Rasmussen
2026-04-28 1:35 ` Barry Song (Xiaomi) [this message]
2026-04-28 4:24 ` Barry Song
2026-04-24 17:03 ` Shakeel Butt
2026-04-26 21:56 ` Barry Song
2026-04-28 18:54 ` Kairui Song
2026-04-28 22:26 ` Barry Song
2026-04-28 22:50 ` Barry Song
2026-04-29 3:17 ` Kairui Song
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=20260428013520.47417-1-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=kasong@tencent.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liulei.rjpt@vivo.com \
--cc=pfalcato@suse.de \
--cc=qi.zheng@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=xueyuan.chen21@gmail.com \
--cc=yuanchu@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