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 5F6BA35972 for ; Thu, 12 Feb 2026 05:04:32 +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=1770872674; cv=none; b=tPK/R3Pu5/z2MX1PH85dP/e5Hxc9h9FN8WFG5tJkP2qnGW47Glj86FwgTgJFcnnPO9CFdZ8EvtHJojHePuRyrWuYZyARR5eJb1KVO2hUU4ne97GLD4YuPnWojh/dbqJPhaC7VXht2+p4K+TXaPaTEMcQz7jT5qXDEjUJf3UU72U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770872674; c=relaxed/simple; bh=+LI2jimcLXG30rp40jFxMo0vtHxesEC/XIOz3WYdex0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mPoSVnq0Ztlht6/Bg/QunnSKV+c2S8auRLLWOTOmhaJe/SldIbNOSP80HxZddfBug0y5vzmr4Lk712csLZSy1qc7s2ma9sIRJ2Op5JYTpFpGL0IhGMjz950xWIM4YjRLVuebGsW0yPniyv9QC4nNfTWfjPi5PB/CtqZ+rN2PTNQ= 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 0CB19339; Wed, 11 Feb 2026 21:04:25 -0800 (PST) Received: from [10.164.148.47] (MacBook-Pro.blr.arm.com [10.164.148.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0CBB83F73F; Wed, 11 Feb 2026 21:04:27 -0800 (PST) Message-ID: Date: Thu, 12 Feb 2026 10:34:18 +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 Cc: "David Hildenbrand (Arm)" , 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> <52ab55c0-6b70-4afc-866d-dd505ff3e85b@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/02/26 7:12 am, Wenchao Hao wrote: > On Wed, Feb 11, 2026 at 12:18 PM Dev Jain wrote: >> >> 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. >> > Thank you for your answer. I think we can now get the following conclusion: > From a hardware perspective, after the PTE continuous bit is set, the access > and dirty flags of the PTE do not affect the transparent PTE > coalescing function. Keep in mind that this is the case in software - there is also transparent coalescing done by hardware, and I am not aware of the spec for that. > >>> 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