All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kairui Song <ryncsn@gmail.com>
To: Baoquan He <hebaoquan@kylinos.cn>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, baohua@kernel.org,
	 kasong@tencent.com, shakeel.butt@linux.dev,
	axelrasmussen@google.com,  yuanchu@google.com,
	weixugc@google.com, david@kernel.org, rostedt@goodmis.org,
	 mhiramat@kernel.org, hannes@cmpxchg.org
Subject: Re: [PATCH v2 3/4] mm/mglru: skip cold PUD subtrees during aging
Date: Sat, 17 Oct 2026 03:53:08 +0800	[thread overview]
Message-ID: <atJwMRHXzXc57qpu@KASONG-MC4> (raw)
In-Reply-To: <20260901063755.1519710-4-hebaoquan@kylinos.cn>

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:

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?


  parent reply	other threads:[~2026-10-16 19:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  6:37 [PATCH v2 0/4] skip empty PUD subtrees during aging with a PUD-level Bloom filter Baoquan He
2026-09-01  6:37 ` [PATCH v2 1/4] mm/mglru: add MM_WALK_EMPTY stats and tracepoint Baoquan He
2026-09-01  7:11   ` Barry Song
2026-09-01  8:18     ` Baoquan He
2026-09-01 23:37       ` Barry Song
2026-09-01  6:37 ` [PATCH v2 2/4] mm/mglru: add PUD-level Bloom filter state and generic helpers Baoquan He
2026-10-16 18:39   ` Kairui Song
2026-09-01  6:37 ` [PATCH v2 3/4] mm/mglru: skip cold PUD subtrees during aging Baoquan He
2026-09-01 23:53   ` Barry Song
2026-09-02  2:29     ` Baoquan He
2026-09-02  3:22     ` Baoquan He
2026-09-04  3:41       ` Barry Song
2026-09-04  4:38         ` Baoquan He
2026-10-16 19:53   ` Kairui Song [this message]
2026-09-01  6:37 ` [PATCH v2 4/4] mm/mglru: count PUD subtrees skipped by the PUD-level filter Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atJwMRHXzXc57qpu@KASONG-MC4 \
    --to=ryncsn@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hebaoquan@kylinos.cn \
    --cc=kasong@tencent.com \
    --cc=linux-mm@kvack.org \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shakeel.butt@linux.dev \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.