From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Zhaoyang Huang <huangzhaoyang@gmail.com>,
steve.kang@unisoc.com
Subject: Re: [PATCHv2] mm: bail out when the PMD has been set in bloom filter
Date: Wed, 4 Mar 2026 10:21:02 +0100 [thread overview]
Message-ID: <d6032abd-eabe-4552-b10e-9f4160edc609@kernel.org> (raw)
In-Reply-To: <20260304031538.1258114-1-zhaoyang.huang@unisoc.com>
On 3/4/26 04:15, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> Part of bloom filter utilization in MGLRU are listed below, in which we
> can see that the step '3' will prevent the hot PMD to be carried to new
> gen since the new arrived rmap_walk clears the page's young flag.
> This commit would like to suggest to query the PMD in bloom filter
> before starting the rmap walk to improve this. In terms of the cost,
> test_bloom_filter only consume 20~30 instructions in modern processors(25
> instructions in ARM64).
This is hard to follow, for example because
* You forward-reference things
* You talk about "this commit". A commit does not suggest anything,
people to.
* It's unclear what the real benefit of the patch is or which problem it
tries to solve.
You could start with a template like the following, where you clearly
express what is currently problematic, and why, and how you are
intending to optimize:
"Currently, lru_gen_look_around() does not properly consider the bloom
filter when processing a PTE. This is suboptimal, because TODO ...
To improve performance, let's consult the bloom filter for the PMD we
are processing, to just skip processing all PTEs in the PMD table.
"
In general, for performance optimizations that are not completely
obvious, we prefer actual proof that it is worth the additional code.
If it's a correctness issue, we should spell that out. I'm still not
sure what it is :)
>
> 1. rmap_walk set suitable PMD in filters[max_seq] while all page's turn
> to be non-young status
> * rmap_walk->lru_gen_look_around->update_bloom_filter(max_seq)
> 2. young pages gathering on the PMD if it is a hot VM area
> 3. newly arrived rmap_walk in the same PMD clears page's young which
> are set in step 2
> 4. walk_mm test the PMD again during aging, which will bring the
> suitable PMD to filters[max_seq+1]
> * walk_mm->walk_pmd_range->test_bloom_fitler->update_bloom_filter(
> walk->seq + 1)
>
> Tested-by: syzbot@syzkaller.appspotmail.com
That doesn't really count as "Tested". It just verified that the problem
in v1 no longer results in a splat, but it didn't really test if the
patch does the right thing.
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> v2: fix null-ptr-ref of mm_state and update commit message
> ---
> ---
> mm/vmscan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 10f1e7d716ca..5558a24d1564 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4234,6 +4234,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 */
That comment is not really helpful given that the code does exactly that.
> + if (mm_state && test_bloom_filter(mm_state, max_seq, pvmw->pmd))
> + return true;
--
Cheers,
David
prev parent reply other threads:[~2026-03-04 9:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 3:15 zhaoyang.huang
2026-03-04 9:21 ` David Hildenbrand (Arm) [this message]
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=d6032abd-eabe-4552-b10e-9f4160edc609@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=hannes@cmpxchg.org \
--cc=huangzhaoyang@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=steve.kang@unisoc.com \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhaoyang.huang@unisoc.com \
--cc=zhengqi.arch@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox