From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a1-smtp.messagingengine.com (flow-a1-smtp.messagingengine.com [103.168.172.136]) (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 618A73054EC for ; Tue, 10 Feb 2026 11:56:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770724573; cv=none; b=leZH9UQN7+S2SkNYuAylQHxsxWl1M7O9L2sIsBKJnhY3YspXURA7DbFtZSzn7HtQLffD2NRfyl3cEdqKEQ+oSbCZi5t5Tiv9mnu7zUxrmg0dex0wypHUx2q+UsyUN3m0MI4Awijy2iUg5EIH1QkjaEzVdttn83D0pSbZ+Zrdde0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770724573; c=relaxed/simple; bh=gEj6j2cmCnOVjvPxwb8jcv+A3rjclaa5ENP0Q3tLcqc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qMc5K4/mMS/1HgxbPlTGujh4bN4uk5BB6/r6ELRGyRMu61bY07wuzweCZ5fZ7uSWdn5yEsxf4Ulvk+MFsE7rv0OADQSq4qfhR9t09s7rt3e+UaMvTH57Cqf2k7mHyKNc1XGMSTnOZISEUqbuPPr38OKEicKhcYnpTQ+29+za1Uo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=ifsyODXD; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=m1eu0+1t; arc=none smtp.client-ip=103.168.172.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="ifsyODXD"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="m1eu0+1t" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.phl.internal (Postfix) with ESMTP id 89ECD1380AEF; Tue, 10 Feb 2026 06:56:11 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Tue, 10 Feb 2026 06:56:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1770724571; x= 1770731771; bh=7OGNsJbKZkIwzInHqy4lEDiFAkNIOQjQRF1xnBL5Q7g=; b=i fsyODXDd0bNNkWf46UvB3kM1dlqAhZdqXTmST6vBg96LZambuf+WsTf2fu7V0EaS U1Vg6fABiIYDzXQhxwpeEGS0569yZRu04hOSgbYwODvkafDzKc5scfHbQl9V3RaQ K1er3oI0VHtnyJdboJrf2qM+crj386eSUDENW/wE7oPhSmkJd/VyzJM8/QvZre3X tSbE9jgfcDfadXLLYn16G3BqRgm72Ik+ymjCGIO+CES7W2UYYJF9zIoUNGh0jgzZ HtmDQxJ8TlSXh/iTYlmy4gFTwj74RIXCIu3QqLLD6wfvRW7+oVmfGHQF5aMpP7nO pLXKIKvgah5rT4Wv6ZBGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1770724571; x=1770731771; bh=7OGNsJbKZkIwzInHqy4lEDiFAkNIOQjQRF1 xnBL5Q7g=; b=m1eu0+1t8dvxUlr3Yh86OyZAQIVh3f+Lz031yVhJes9vgQ2viJR nYdFCQA7FduAvnbzM4QpVEna0cdykPFLp8N0/SOxBPtG2J0lYNneDJNrux+KqYFw lnsZTQ6ZBAJWUGCxnHBYRkoIoHwCi1PtFiUlb72s6INU8b6xX06iZ29PHya8ZdR9 63mBZrsMx6g7iKU/LyOTVtCVtB+ZWVuXFdiXf82kuHQcHfMUEuWWy7qByBqPwQ2j 2mehtN9ATlxFk0uy6RWnUGVHPn0JCiV25PvgCRikv/M5CUXrnKAXNvR0cyUXqUkb /N+j+JkGIS+O7iHE9yCL4FLTOj/qhVPp+uw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduleelieduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvgeqnecugg ftrfgrthhtvghrnhepfeetheejudeujeeikeetudelvdevkeefuddtkedvtdehtdetieeu ieetjeeugedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepkhhirhhilhhlsehshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopedv vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohephhgrohifvghntghhrghovddvse hgmhgrihhlrdgtohhmpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgurght ihhonhdrohhrghdprhgtphhtthhopegurghvihgusehkvghrnhgvlhdrohhrghdprhgtph htthhopehlohhrvghniihordhsthhorghkvghssehorhgrtghlvgdrtghomhdprhgtphht thhopehlihgrmhdrhhhofihlvghtthesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepvh gsrggskhgrsehsuhhsvgdrtgiipdhrtghpthhtoheprhhpphhtsehkvghrnhgvlhdrohhr ghdprhgtphhtthhopehsuhhrvghnsgesghhoohhglhgvrdgtohhmpdhrtghpthhtohepmh hhohgtkhhosehsuhhsvgdrtghomh X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 10 Feb 2026 06:56:09 -0500 (EST) Date: Tue, 10 Feb 2026 11:56:04 +0000 From: Kiryl Shutsemau To: Wenchao Hao Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page Message-ID: References: <20260210043456.2137482-1-haowenchao22@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260210043456.2137482-1-haowenchao22@gmail.com> On Tue, Feb 10, 2026 at 12:34:56PM +0800, Wenchao Hao wrote: > When do_anonymous_page() creates mappings for huge pages, it currently sets > the access bit for all mapped PTEs (Page Table Entries) by default. > > This causes an issue where the Referenced field in /proc/pid/smaps cannot > distinguish whether a page was actually accessed. > > So here introduces a new interface, set_anon_ptes(), which only sets the > access bit for the PTE corresponding to the faulting address. This allows > accurate tracking of page access status in /proc/pid/smaps before memory > reclaim scan the folios. > > During memory reclaim: folio_referenced() checks and clears the access bits > of PTEs, rmap verifies all PTEs under a folio. If any PTE mapped subpage of > folio has access bit set, the folio is retained during reclaim. So only > set the access bit for the faulting PTE in do_anonymous_page() is safe, as > it does not interfere with reclaim decisions. We had similar discussion about faultaround and briefly made it produce old ptes, but it caused performance regression as old ptes require additional pagewalk to set accessed bit on touch. It got reverted, but arch can opt-in for setting up old ptes for non-fault address. See commits: 5c0a85fad949 ("mm: make faultaround produce old ptes") 315d09bf30c2 ("Revert "mm: make faultaround produce old ptes"") 46bdb4277f98 ("mm: Allow architectures to request 'old' entries when prefaulting") -- Kiryl Shutsemau / Kirill A. Shutemov