From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8984D226CFE for ; Wed, 11 Feb 2026 04:18:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770783537; cv=none; b=GOtMOfEez2b6bJ+SxksGUTrprF8FiRsXP8HCCSXkVmSKQcoKKG2SBRZ9io8WcrVNzsB/ulm4rZSVf0C36AxnrcJuT1JIcPN459Vab4G6HhGM9PBZUEzpSOWaf0AbhJG30vW5TyHEHHAcfwxrZgQdXtiROipMIic9QhwrdzC69Rg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770783537; c=relaxed/simple; bh=GoNia19sE5JxJTF/7e9eEhNBEgLtCnk0qUI/60l/U14=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=etjS5KG7sadd+NjUjynmOEs8Rdi9jD/8Sjcp9IAOfnXU8wNiiw+N4SwotmwTa5JahRG8AAuDFo1om+TytkxgROM298o9lhgnKYyR0/2NjThrh5waclDiL7316NkcBGGhXnUvkO80oL1F9eI6ZscgMeTlY50RhcHfzc2rG7vxkwg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1667D339; Tue, 10 Feb 2026 20:18:47 -0800 (PST) Received: from [10.164.148.41] (MacBook-Pro.blr.arm.com [10.164.148.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ED8933F632; Tue, 10 Feb 2026 20:18:49 -0800 (PST) Message-ID: <52ab55c0-6b70-4afc-866d-dd505ff3e85b@arm.com> Date: Wed, 11 Feb 2026 09:48:40 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page To: Wenchao Hao , "David Hildenbrand (Arm)" Cc: Andrew Morton , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260210043456.2137482-1-haowenchao22@gmail.com> <5c4d773c-e3e7-4a71-b250-91701cbdd4a2@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/02/26 6:19 am, Wenchao Hao wrote: > On Tue, Feb 10, 2026 at 5:07 PM David Hildenbrand (Arm) > wrote: >> On 2/10/26 05:34, 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. >> What is the use case that cares about that? >> > We have enabled 64KB large folios on Android devices, which may introduce > some memory waste. I want to figure out the proportion of memory waste > caused by large folios. Reading the "Referenced" field from /proc/pid/smaps > is a relatively low-cost method. > > Additionally, considering future hot/cold page identification, we aim to > detect 64KB large folios where some pages are actually unaccessed and split > them into normal pages to avoid memory waste. > > However, the current large folio implementation sets the access bit for all > page table entries (PTEs) of the large folio in the do_anonymous_page > function, making it hard to distinguish whether pre-allocated pages were > truly accessed. > >> What we have right now is the exact same behavior as if you would get a >> PMD THP that has a single access+dirty bit at fault time. >> >> Also, architectures that support transparent PTE coalescing will not be >> able to coalesce until all PTE bits are equal. >> >> This level of imprecision is to be expected with large folios that only >> have a single access+dirty bit. >> > Thanks a lot for the response. > > I saw this description in the ARM manual, “D8.5.5 Use of the Contiguous bit > with hardware updates to the translation tables”: > > >> If hardware updates a translation table entry, and if the Contiguous bit in >> that entry is 1, then the members in a group of contiguous translation table >> entries can have different AF, AP[2], and S2AP[1] values. > Does this mean that after hardware aggregates multiple PTEs, it can still > independently set the AF and other flag bits corresponding to specific > sub-PTE? Yes. Hardware can update access and dirty bits per-pte. It is the job of software to aggregate them. > > If so, can software also set different AF bits for a group of 16 PTEs > without affecting the transparent PTE coalescing function? Yes. See set_ptes -> __contpte_try_fold: look at pte_mkold(pte_mkclean()). We ignore the a/d bits while constructing the next expected pte. > > The reason I have this confusion is that there is such a description in > “D8.7.1 The Contiguous bit:” > >> Software is required to ensure that all of the adjacent translation table >> entries for the contiguous region point to a contiguous OA range with >> consistent attributes and permissions. > It does not specify whether attributes and permissions include the AF bit. > >> -- >> Cheers, >> >> David