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

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

Hi Kairui,

On 10/17/26 at 03:53am, Kairui Song wrote:
> On Tue, Sep 01, 2026 at 02:37:54PM +0800, Baoquan He 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);
> > +	}
> 
> I saw the discussion from Barry about the concern about the overhead
> 
> I think we can drop the PUD ptr walk entirely. The filter only
> needs a stable identity for the range walk_pud_range() is iterating,
> and (mm, PUD-aligned address) gives that on both sides:
> 
>    walk_pud_range(), test and update alike:
>       (void *)((unsigned long)args->mm ^ (addr & PUD_MASK))
> 
>    lru_gen_look_around():
>       (void *)((unsigned long)vma->vm_mm ^ (pvmw->address & PUD_MASK))
> 
> Will this work? Also I took a look at the hash algorithm of this too:

Sorry, missed this mail too, thanks for great suggestion.

Yeah, it's a much better way to do pud level filtering. I will
switch to it in v3.

And the same idea on PMD has been merged, your suggestion is earlier
than it.
65a9bf08a3e4 mm/mglru: don't use stack pointers when walking PUD and PMD tables

> 
> static void get_item_key(void *item, int *key)
> {
> 	u32 hash = hash_ptr(item, BLOOM_FILTER_SHIFT * 2);
> 
> 	BUILD_BUG_ON(BLOOM_FILTER_SHIFT * 2 > BITS_PER_TYPE(u32));
> 
> 	key[0] = hash & (BIT(BLOOM_FILTER_SHIFT) - 1);
> 	key[1] = hash >> BLOOM_FILTER_SHIFT;
> }
> 
> And hash_ptr is actually hash_long, 64 bits if we use hash_32
> will it be even better?

Right, hash_ptr() is hash_long(), i.e. hash_64() on 64-bit: it hashes the
full 64-bit value and returns the top 30 bits of val * GOLDEN_RATIO_64.
The 30-bit width comes from BLOOM_FILTER_SHIFT * 2.

With the v2 pud pointer as the key, page table pointers share most of
their high bits, e.g (0xffff8...). But with the new way you just
suggested, it's the other way around. With the (mm, PUD-aligned addr)
key the low 30 bits are cleared by PUD_MASK, so the address difference
lives above bit 32 - hash_32() would truncate the key there, and two
PUDs every 4GB in the same mm would get the same keys and always share
Bloom bits. Please correct me if I am wrong.

Thanks
Baoquan