From: Barry Song <21cnbao@gmail.com>
To: wangzicheng <wangzicheng@honor.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Lei Liu <liulei.rjpt@vivo.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Kairui Song <kasong@tencent.com>,
Tangquan Zheng <zhengtangquan@oppo.com>,
wangtao <tao.wangtao@honor.com>
Subject: Re: [PATCH RFC] mm/mglru: lazily activate folios while folios are really mapped
Date: Fri, 27 Feb 2026 08:15:50 +0800 [thread overview]
Message-ID: <CAGsJ_4wV=OpV-ntZQGKQawrO0kemwdT8byySBCCZiOOgugcQtw@mail.gmail.com> (raw)
In-Reply-To: <2558f7d82b9a482387960f45409e1b76@honor.com>
Hi Zicheng,
On Thu, Feb 26, 2026 at 8:57 PM wangzicheng <wangzicheng@honor.com> wrote:
[...]
> > /**
> > * folio_add_lru - Add a folio to an LRU list.
> > * @folio: The folio to be added to the LRU.
> > @@ -506,7 +519,8 @@ void folio_add_lru(struct folio *folio)
> > /* see the comment in lru_gen_folio_seq() */
> > if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
> > lru_gen_in_fault() && !(current->flags & PF_MEMALLOC))
> > - folio_set_active(folio);
> > + if (!folio_is_file_lru(folio))
> > + folio_set_active(folio);
> >
> > folio_batch_add_and_move(folio, lru_add);
> > }
> > --
> > 2.39.3 (Apple Git-146)
>
> Hi Barry,
>
> Setting only non-filelru-folio in folio_add_lru looks reasonable and
> should help with over-protecting readahead pages that are never
> actually accessed.
>
> For our workloads that already suffer from file under-protection, we see two
> sides here: on the positive side, keeping only actually-used readahead pages
> in memory could improve performance; on the other hand, since we already
Right, the fundamental principle of LRU is to place cold pages at
the tail, not at the head, making cold pages easier to reclaim and
hot pages harder to reclaim.
> see file under-protect issues, it's not clear whether this change might
> exacerbate that or even hurt performance.
I find your concern a bit surprising. If I understand correctly,
you’re observing that file folios are currently being over-reclaimed.
In that case, placing hot pages at the tail might make them harder
to reclaim after PTE scanning (since they may still be young), but
this seems to violate the fundamental principle of LRU. Moreover,
when scanning encounters young file folios, reclaim will simply
continue scanning more folios to find reclaimable ones, so scanning
hot folios only wastes CPU time.
Since read-ahead cold folios are placed at the head, relatively hotter
folios may be reclaimed instead, causing refaults and further triggering
reclaim, which can worsen the situation.
>
> We'll test this when available and report back. We hope to have a
> chance to discuss this topic at LSF/MM/BPF.
>
Sure, thanks!
Barry
next prev parent reply other threads:[~2026-02-27 0:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 22:37 Barry Song
2026-02-26 12:57 ` wangzicheng
2026-02-27 0:15 ` Barry Song [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-02-25 21:26 Barry 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='CAGsJ_4wV=OpV-ntZQGKQawrO0kemwdT8byySBCCZiOOgugcQtw@mail.gmail.com' \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liulei.rjpt@vivo.com \
--cc=surenb@google.com \
--cc=tao.wangtao@honor.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
--cc=zhengtangquan@oppo.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