Re: [RFC PATCH 1/6] mm/mglru: add PUD-level Bloom filter state

On 08/15/26 at 07:20am, Barry Song wrote:
> On Thu, Aug 6, 2026 at 6:30 PM Baoquan He <[email protected]> wrote:
> >
> > Add a second, coarser pair of double-buffered Bloom filters to
> > struct lru_gen_mm_state. Like the PMD-level filters, they flip
> > each generation, but they operate at 1GB (PUD) granularity so the
> > page table walker can skip whole PUD subtrees whose 512 PMDs would
> > all fail the PMD-level filter. This mainly targets the page tables
> > of processes whose memory lives only on other NUMA nodes
> > (cross-node empty walks).
> >
> > No behavior change yet; the filters are populated and consumed by
> > follow-up patches.
> >
> > Signed-off-by: Baoquan He <[email protected]>
> > ---
> >  include/linux/mmzone.h | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index a26c8b855222..2bda24522d9f 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -608,8 +608,16 @@ struct lru_gen_mm_state {
> >         struct list_head *head;
> >         /* where the last iteration ended before */
> >         struct list_head *tail;
> > -       /* Bloom filters flip after each iteration */
> > +       /* PMD-level Bloom filters flip after each iteration */
> >         unsigned long *filters[NR_BLOOM_FILTERS];
> > +       /*
> > +        * PUD-level Bloom filters flip after each iteration. Same double
> > +        * buffering as the PMD-level filters, but coarser: they remember
> > +        * which 1GB PUD subtrees had young leaf entries last generation,
> > +        * so walk_pud_range() can skip whole subtrees whose PMD iteration
> > +        * would find nothing worth scanning (e.g. cross-node empty walks).
> > +        */
> > +       unsigned long *pud_filters[NR_BLOOM_FILTERS];
> 
> Could we rename them to pmd_filters and pud_filters rather
> than filters and pud_filters? The current naming looks a bit
> inconsistent.
> 
> I also feel the names are quite self-explanatory, so perhaps we don't
> need such a long comment here?

Thanks for careful reviewing, and this is a great idea, will change it
as suggested.

> 
> >         /* the mm stats for debugging */
> >         unsigned long stats[NR_HIST_GENS][NR_MM_STATS];
> >  };
> > --
> > 2.54.0
> >
> 
> Best Regards
> Barry