Re: [PATCH v2 3/4] mm/mglru: skip cold PUD subtrees during aging

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

On 09/04/26 at 11:41am, Barry Song wrote:
> On Wed, Sep 2, 2026 at 11:22 AM Baoquan He <baoquan.he@linux.dev> wrote:
> >
> > On 09/02/26 at 07:53am, Barry Song wrote:
> > > On Tue, Sep 1, 2026 at 2:38 PM Baoquan He <hebaoquan@kylinos.cn> wrote:
> > > >
> > > > The aging walks into every PUD and runs the PMD-level Bloom filter
> > > > on each PMD. Add a coarser PUD-level filter (pud_filters) one level
> > > > up:
> > > >  - walk_pmd_range() now reports whether it found any young leaf entries,
> > > >  - walk_pud_range() records that in the PUD filter, and
> > > >  - on subsequent generations, skips the whole 1GB subtree when the filter
> > > >    says it had none last generation.
> > > >
> > > > The double-buffered filter flips with each new iteration, so newly hot or
> > > > migrated-in pages are re-checked promptly rather than suppressed
> > > > indefinitely. force_scan walks bypass the PUD test, so manual aging and
> > > > newly added mm's always rescan and re-populate the filter.
> > > >
> > > > To keep hot regions marked, also report the covering PUD from the rmap
> > > > feedback path (lru_gen_look_around()), so regions whose hotness is only
> > > > observed by eviction will be re-scanned.
> > > >
> > > > Signed-off-by: Baoquan He <hebaoquan@kylinos.cn>
> > > > ---
> > > >  mm/vmscan.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++-----
> > > >  1 file changed, 47 insertions(+), 5 deletions(-)
> > > [...]
> > > > @@ -4397,8 +4431,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_pmd_bloom_filter(mm_state, max_seq, pvmw->pmd);
> > > > +               update_pud_bloom_filter(mm_state, max_seq, pud_p);
> > > > +       }
> > >
> > >
> > > Hi Baoquan,
> > >
> > > I am really not against this idea, and I believe it can benefit
> > > NUMA cases.
> > >
> > > That said, I might be being overly cautious, but I'm a bit concerned
> > > that this re-walk of the page tables could slightly hurt machines that
> > > don't benefit from the PUD filter at all. For example, Android devices
> > > typically have relatively small amounts of memory, so a PUD covers a
> > > really large range of their address space, which is unlikely to be
> > > useful on an 8 GB Android device. Also, `lru_gen_look_around()` is a
> > > really hot path. On Android, we've observed that it can consume a
> > > significant amount of CPU.
> > >
> > > Is there any possibility of implementing this in a low-cost way?
> >
> > I made a draft patch, could you help check and test if it's performing
> > better on Andriod device?
> >
> 
> Hi Baoquan,
> 
> Actually, it is quite difficult to run the latest kernel, or even a
> patch against the latest kernel, on an Android device. However, I can
> run it on my x86 PC, for example, by setting `mem=4096M` or `mem=8192M`
> in the bootargs to simulate a low-end phone.
> 
> I may run kernel-build on it and collect the perf data. Once I have
> the data, I'll get back to you.
> 
> On the other hand, you could also investigate this in parallel by
> emulating a low-end device. :-)

Sure, I will test and investigate from my side. Thank you very much for
the effort on testing and investigation.