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

On Thu, Aug 6, 2026 at 6:30 PM Baoquan He <[email protected]> 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 <[email protected]>
> ---
>  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.

> +       }
>
>         mem_cgroup_put(memcg);
>

Best Regards
Barry