Re: [PATCH] mm: bail out when the PMD has been set in bloom filter

[Zhaoyang Huang <huangzhaoyang@gmail.com>]

On Sun, Mar 1, 2026 at 2:14 PM Gregory Price <gourry@gourry.net> wrote:
>
> On Fri, Feb 27, 2026 at 03:52:50PM +0800, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > There are two reasons to have the recorded PMD bail out from doing
> > the following iteration
> > 1. It is worth of doing such a trade off thing in terms of reclaiming
> > efficiency as test_bloom_filter only consume 20~30 instructions in modern
> > processors(25 instructions in ARM64).
> > 2. The PMD needs to accumulate young pages until aging happens while the
> > new arrived folio reference checking under current max_seq refuse to do so
> > which will affect carrying hot PMDs to new generation.
> >
>
> Can you explain what the intended *effect* of this patch is?
>
> Why does the PMD need to accumulate young pages?
Please allow me to be more clear by summarizing the bloom filter's
utilization below
1. rmap_walk has the suitable PMD set in filters[max_seq] while all
page's turn to be non-young states
     rmap_walk->lru_gen_look_around->update_bloom_filter(max_seq)
2. young pages gathering on the PMD if it is a hot VM area
3. newly arrived rmap_walk in the same PMD clears page's young which
is set in step 2
4. walk_mm test the PMD again during aging, which will bring the
suitable PMD to filters[max_seq+1]
    walk_mm->walk_pmd_range->test_bloom_fitler->update_bloom_filter(walk->seq
+ 1)
> Why does this patch help that?
This patch has the rmap_walk check the PMD from the filter first to
prevent step 3 from happening until reset_bloom_filter happens
> How does this affect carrying hot PMDs to the new generation?
The hot PMD will keep the page's young flag until it is tested again in walk_mm
>
> What concrete behavior did you see before this patch, and how does
> this patch change that behavior?
The debug log shows there are a certain amount of PMDs bypassed via
the newly inserted criteria which save instructions of walking the
ptes at least.
>
> What is the user-facing effects before / after this patch?
The regression test is on-going.
>
> Is this fixing a bug or a tweak to the MGLRU heuristics?
It is a tweak.
>
> ~Gregory
>
> > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> > ---
> >  mm/vmscan.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 9d900be478ea..e50e98291d0d 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4227,6 +4227,10 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
> >       /* avoid taking the LRU lock under the PTL when possible */
> >       walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
> >
> > +     /* may the pmd has been set in bloom filter */
> > +     if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> > +             return true;
> > +
> >       start = max(addr & PMD_MASK, vma->vm_start);
> >       end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
> >
> > --
> > 2.25.1
> >