From nobody Thu Apr 9 12:09:51 2026 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 714BEC2FF for ; Wed, 4 Mar 2026 03:15:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=222.66.158.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772594162; cv=none; b=G8P+dtWg13he30KuDPiTJVo67YzMXDrPCLySRpmdnckj+AzuVEV8c/ZA7N2h+9ubmj1d4MUWSni+roib5GfkRvOlNrLxjEPTM2wCoQ36hmDWAeXF91/hFVyaND4d5hkH3If6MBYQr3I+zZ19b/rLvV8L/43hFUdnM1qUvVSlYPE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772594162; c=relaxed/simple; bh=OOyAQWRA8k79i4kzokGwk5MGucbDoWMjZvm43ArakJY=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=bQPai9xmn+4aKtyrVRfd1Mcst0K9FnNaNKhRhpLpGb4KIWQjYNfOl+b76dHNKk/+sfio7oEoTlr6mjCKSWDy0dP2qiYK8kN9Xk45Vz782tmw0DxgQEGWrREi0L8Q2fzIAkdLVzOcIYYUpJyIetu6cmFTZ85GuHn/qc9YA7XqdPM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com; spf=pass smtp.mailfrom=unisoc.com; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b=ISFFZiOA; arc=none smtp.client-ip=222.66.158.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=unisoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b="ISFFZiOA" Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 6243FnAK024267; Wed, 4 Mar 2026 11:15:49 +0800 (+08) (envelope-from zhaoyang.huang@unisoc.com) Received: from SHDLP.spreadtrum.com (BJMBX01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4fQd7r1Zdlz2K5B73; Wed, 4 Mar 2026 11:14:48 +0800 (CST) Received: from bj03382pcu03.spreadtrum.com (10.0.73.40) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Wed, 4 Mar 2026 11:15:46 +0800 From: "zhaoyang.huang" To: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , , , Zhaoyang Huang , Subject: [PATCHv2] mm: bail out when the PMD has been set in bloom filter Date: Wed, 4 Mar 2026 11:15:38 +0800 Message-ID: <20260304031538.1258114-1-zhaoyang.huang@unisoc.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: SHCAS01.spreadtrum.com (10.0.1.201) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 6243FnAK024267 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unisoc.com; s=default; t=1772594154; bh=KfnvDCmMijENkfP7CLbZ+G9AhpOwRR2K7/fT4/nxWQE=; h=From:To:Subject:Date; b=ISFFZiOAQyTI3Pcoxp/NEOkldDEe7O+2vDWQfM1dVJ8B0Aikkho+l9HEbMswv+Gcy 9oEJAQFQ9OMmTq0t/I3okjfAEFGUHAoKFFAbwT02xyyXkz0Fy/hJ6WFMBAnX/0uJOw 3x8mAPSU7+smhr+GaocoeguKAN19VQ0D8GdCCog/+xwe2srZaxvftcM7jpaS198UYW oI25DaZAEdFXiRKgZrPzMbhpYdctxkkLjtTxYjvD8z4F/4I93p6dcZrvNzuIbJ1khG zqOkuTvvvkHA56HhhFXTxac76QxIgEFOx2jfPNcd/eiESsxQHEpvolD92uNsccXmTz XWZTpJVf0N2qg== Content-Type: text/plain; charset="utf-8" From: Zhaoyang Huang 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). 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 Signed-off-by: Zhaoyang Huang --- 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 =3D current->reclaim_state ? current->reclaim_state->mm_walk : NULL; =20 + /* may the pmd has been set in bloom filter */ + if (mm_state && test_bloom_filter(mm_state, max_seq, pvmw->pmd)) + return true; + start =3D max(addr & PMD_MASK, vma->vm_start); end =3D min(addr | ~PMD_MASK, vma->vm_end - 1) + 1; =20 --=20 2.25.1