Re: [PATCH] mm: bail out when the PMD has been set in bloom filter
From: Gregory Price
Date: Sun Mar 01 2026 - 01:15:03 EST
On Fri, Feb 27, 2026 at 03:52:50PM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
>
> There are two reasons to have the recorded PMD bail out from doing
> the following iteration
> 1. It is worth of doing such a trade off thing in terms of reclaiming
> efficiency as test_bloom_filter only consume 20~30 instructions in modern
> processors(25 instructions in ARM64).
> 2. The PMD needs to accumulate young pages until aging happens while the
> new arrived folio reference checking under current max_seq refuse to do so
> which will affect carrying hot PMDs to new generation.
>
Can you explain what the intended *effect* of this patch is?
Why does the PMD need to accumulate young pages?
Why does this patch help that?
How does this affect carrying hot PMDs to the new generation?
What concrete behavior did you see before this patch, and how does
this patch change that behavior?
What is the user-facing effects before / after this patch?
Is this fixing a bug or a tweak to the MGLRU heuristics?
~Gregory
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
> ---
> mm/vmscan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 9d900be478ea..e50e98291d0d 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4227,6 +4227,10 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
> /* avoid taking the LRU lock under the PTL when possible */
> walk = current->reclaim_state ? current->reclaim_state->mm_walk : NULL;
>
> + /* may the pmd has been set in bloom filter */
> + if (test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> + return true;
> +
> start = max(addr & PMD_MASK, vma->vm_start);
> end = min(addr | ~PMD_MASK, vma->vm_end - 1) + 1;
>
> --
> 2.25.1
>