From: Baoquan He <baoquan.he@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: Baoquan He <hebaoquan@kylinos.cn>,
linux-mm@kvack.org, akpm@linux-foundation.org, david@kernel.org,
rostedt@goodmis.org, mhiramat@kernel.org, kasong@tencent.com,
qi.zheng@linux.dev, shakeel.butt@linux.dev,
axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com,
baolin.wang@linux.alibaba.com, hannes@cmpxchg.org
Subject: Re: [PATCH 0/9] mm/mglru: suppress empty page table walks during aging
Date: Fri, 28 Aug 2026 15:42:56 +0800 [thread overview]
Message-ID: <apE8AAk-nVwa4tvs@fedora> (raw)
In-Reply-To: <CAGsJ_4yDgCt6C7tS5YR8Je0OEPoYFgXNbG-T5KLmF+EdBHA9=w@mail.gmail.com>
On 08/28/26 at 02:11pm, Barry Song wrote:
> On Mon, Aug 24, 2026 at 3:38 PM Baoquan He <hebaoquan@kylinos.cn> wrote:
> >
> > In the current MGLRU, lru_gen_use_mm() will mark an mm for all nodes at
> > each context switch, so on each node aging will walk into each mm's page
> > table independently. On a multi-NUMA node system, one process launched
> > on one or a subset of nodes, its mm is walked by all other nodes's aging
> > while finds on pages for their lruvec. This is pure waste (100% walks
>
> I assume you mean “finds no pages” rather than “find on pages.”
You are right, typo, thanks.
>
> > are empty on those other nodes)
> >
> > This patch series suppresses these empty page table walks with two
> > complementary mechanisms at different levels:
> >
> > - empty_map (cross-node specifc). At mm granularity, one process's mm
> > whose walk found no pages for one node's lruvec is skipped on that
> > node between re-scan passes.
> >
> > - PUD-level Bloom filter (general). One level up from the existing PMD
> > filters, it skips any 1GB PUD that had no young entries last
> > generation - namely whose 512 PMDs all failed PMD test. Cross-node
> > empty walks can prove its effect the best, but it also suppresses
> > purely code PUD inside local mms. So it reduces unnecessary walking
> > in any workload with cold areas.
>
> I assume you mean “purely cold PUD” rather than “purely code PUD”.
Right, thanks.
>
> >
> > The two complement each other: empty_map reduces the *number* of
> > cross-node walks, the PUD-level filter reduces the *cost* of the walks
> > that remain.
>
> I wonder if the PUD-level filter alone would achieve your goal without
> requiring the more complex `empty_map` code.
>
> PUD is already a fairly large granularity, so even if we still do some
> redundant work, I wonder if the overhead would be small enough to make
> `empty_map` unnecessary?
As replied to you in patch 2 thread, will take PUD filter alone in v2
as you suggested, thanks.
prev parent reply other threads:[~2026-08-28 7:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 7:37 [PATCH 0/9] mm/mglru: suppress empty page table walks during aging Baoquan He
2026-08-24 7:37 ` [PATCH 1/9] mm/mglru: add MM_WALK_EMPTY stats and tracepoint Baoquan He
2026-08-28 5:37 ` Barry Song
2026-08-28 7:46 ` Baoquan He
2026-08-31 8:17 ` Baoquan He
2026-08-24 7:37 ` [PATCH 2/9] mm/mglru: suppress cross-node empty page table walks Baoquan He
2026-08-28 6:35 ` Barry Song
2026-08-28 7:26 ` Baoquan He
2026-08-24 7:38 ` [PATCH 3/9] mm/mglru: add debugfs knob for the empty-walk skip threshold Baoquan He
2026-08-24 7:38 ` [PATCH 4/9] mm/mglru: invalidate empty-walk skip on page fault and migration Baoquan He
2026-08-24 7:38 ` [PATCH 5/9] mm/mglru: add PUD-level Bloom filter state Baoquan He
2026-08-24 7:38 ` [PATCH 6/9] mm/mglru: refactor Bloom filter helpers for two filter levels Baoquan He
2026-08-24 7:38 ` [PATCH 7/9] mm/mglru: skip PUD subtrees during aging Baoquan He
2026-08-24 7:38 ` [PATCH 8/9] mm/mglru: report hot PUDs from the rmap feedback path Baoquan He
2026-08-24 7:38 ` [PATCH 9/9] mm/mglru: count PUD subtrees skipped by the PUD-level filter Baoquan He
2026-08-24 8:11 ` [PATCH 0/9] mm/mglru: suppress empty page table walks during aging Baoquan He
2026-08-24 8:42 ` Baoquan He
2026-08-28 6:11 ` Barry Song
2026-08-28 7:42 ` Baoquan He [this message]
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=apE8AAk-nVwa4tvs@fedora \
--to=baoquan.he@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hebaoquan@kylinos.cn \
--cc=kasong@tencent.com \
--cc=linux-mm@kvack.org \
--cc=mhiramat@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.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