Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.



      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