Re: [RFC PATCH 4/6] mm/mglru: report hot PUDs from the rmap feedback path

[Baoquan He <baoquan.he@linux.dev>]

On 08/15/26 at 07:36am, Barry Song wrote:
> On Thu, Aug 6, 2026 at 6:30 PM Baoquan He <baoquan.he@linux.dev> wrote:
> >
> > lru_gen_look_around() marks the PMD of a young PTE found during the
> > eviction rmap walk, feeding hot regions back to the aging walker.
> > With the PUD-level filter in place, that PMD marking alone is not
> > enough: the next aging walk would test the containing PUD first and
> > skip the whole 1GB subtree if the PUD is unmarked, never reaching the
> > PMD. Mark the covering PUD as well, so regions whose hotness is only
> > observed by eviction keep getting re-scanned by aging.
> >
> > The PUD entry is re-derived from the mm page tables via pgd_offset()/
> > p4d_offset()/pud_offset(); it is only hashed, never dereferenced, and
> > the mmap lock held by the rmap walk keeps the table chain valid.
> >
> > Signed-off-by: Baoquan He <baoquan.he@linux.dev>
> > ---
> >  mm/vmscan.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 74edfe2a747d..ca0f06641adc 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4416,8 +4416,14 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
> >         lazy_mmu_mode_disable();
> >
> >         /* feedback from rmap walkers to page table walkers */
> > -       if (mm_state && suitable_to_scan(i, young))
> > +       if (mm_state && suitable_to_scan(i, young)) {
> > +               /* the PUD entry covering the young PTEs scanned above */
> > +               pud_t *pud_p = pud_offset(p4d_offset(pgd_offset(vma->vm_mm, pvmw->address),
> > +                                                    pvmw->address), pvmw->address);
> > +
> >                 update_bloom_filter(mm_state, max_seq, pvmw->pmd);
> > +               update_pud_bloom_filter(mm_state, max_seq, pud_p);
> 
> Is there a case where all PMDs return suitable_to_scan() == false,
> but the PUD is still worth updating? Or, if only one PMD returns
> suitable_to_scan() == true while the other 511 return false, is the
> PUD still worth updating?
> It seems we can keep it simple. I was just thinking through some
> extreme cases — maybe I'm overthinking it.

Good questions.

The PUD update uses the same suitable_to_scan() gate as the PMD filter: 
walk_pte_range() returns suitable_to_scan(), just as lru_gen_look_around()
does. So a PUD is marked if any of its PMDs shows dense enough young
activity. If no PMD passes, the PUD is left unmarked by both paths on
purpose: sparse young pages don't justify walking the whole 1GB subtree. 
Those young pages in unmarked PMD/PUDs are not lost: they are deferred
to eviction, which doesn't check filters but checks their actual PTE young
bits via folio_referenced(). Young ones are kept , and lru_gen_look_around() 
then re-marks the covering PUD, or cold ones are reclaimed. So I'll keep it
simple.

> 
> > +       }
> >
> >         mem_cgroup_put(memcg);
> >
> 
> Best Regards
> Barry