From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f42.google.com (mail-yx1-f42.google.com [74.125.224.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00E2C42049 for ; Thu, 12 Feb 2026 01:43:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.224.42 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770860586; cv=pass; b=KAuvrBPcmnsVhMvSyadaLaDYsuWT0KBAMaC8o5EN2zHvNUAgtIYf5pVOEdSEgfMF6Cri09eDnvvZy9KnkYQjRp8APsfbUPfCsvRe1DMuOZirRauxuapyR477uKu1bOowfMNGhroE2d3ZCyArUM6P8xsyZaXOxO5mspmtk5RWiLM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770860586; c=relaxed/simple; bh=pQNNV1lyjEdP2OrQfDb/AG8ogO9dTjL4vmNELjD2OdI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=soM5fjKlhuUhkXOSqvaABNaETIM5Dj7U1NUCaoKFuiPJZSkjMAx6zM0iWXpgAxZq5304F1pHmq8nTqt26sCrodO/wn0TBl7bw/yWAmNzGezIo1Be8dos3mE6mMNHCmg+7G2fTanHcyJ9yOzOa7ZIX64IrECCB6ns7sc7iRsMkNs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XjYapL8k; arc=pass smtp.client-ip=74.125.224.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XjYapL8k" Received: by mail-yx1-f42.google.com with SMTP id 956f58d0204a3-64a28af2f4cso2404231d50.1 for ; Wed, 11 Feb 2026 17:43:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770860584; cv=none; d=google.com; s=arc-20240605; b=CPRHBBULXeqYi6HmRwYOZpR4cIn94M88jJiEdzFwKl0colHeMnqYDRNCqHnixT61cr YGLfXKFTjlqZcwjeP144KML104A1of9L5F3k6DOHz2Of4iTk7cs7A3feafVpA2Un704y WWScerEfWtj4UogYkTCDvyGkoApybrAptKnpK7/kM4ZTQLYaz942VLoDKUq0yxqLUDIV vuwFGoaXKpracByOpQgAmYKaIIgHKdjr/WK3GrtYyJ0YZNwRpIWKZJ8aBW8BSCQ9PV5p eKJJrThYmP+2PnGTtQt0IAtP1n8WT2TpN4S6OH64IrezAdEfMMDymcLdfLZYK1YY8dh1 SCxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=pQNNV1lyjEdP2OrQfDb/AG8ogO9dTjL4vmNELjD2OdI=; fh=Dyp28nlf/gaHz4x5ovSabFH7Yxd2zCRt9tEfrSwMDDA=; b=QLab/JnQNT4W/pJz9u5D2Gt85YzIRh/sf7DUCgvUWRpRNv+VWbkc4cK07bZwxpcVA1 NYuQ05w2uVfczz8FpWxRx5qh3aJ89Xjpgv8EC1o8wjhgb2cG7FY+cqAtLH+xtbF1zbvN DUa7gJidL6iscyb9QHxGOIYXzUyzT5bkC7YzxvSwsoIScQSylm+tt/mRyNHa2lQKSooU p9UrUvSVWd01vp/+/lDSjymh4gH59v5fiE6Nf7KGodFpoeGYixLbcna5B2kgU4IGiM7u 7mq7F78BPrttumd98TE3NY6KJJJJIvdNBai8YiWcnRu1ZzwA/gKLsrXbmDqAs7j4c1O8 wZIw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770860584; x=1771465384; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pQNNV1lyjEdP2OrQfDb/AG8ogO9dTjL4vmNELjD2OdI=; b=XjYapL8kzkGerG5Dxx0qXbGoYbfKGDFLW0gslgdlTY8ZzoFl7aJE9/puziQ5LZ8lCZ aON7x16ShrQOqPr/9KOu8i+gF30ZvBvBi9vfi8uvwEEKO/+L3bPLrMry+3+6SsrpuHSy Zm8Ts3YjF/JSbdLXuduKwxKPS3ArzyLdou7tJyibLtIG4wxfei5RDvgSqLe7naty5leS hqwFlN82lDw3knBqwBB21FLvAPP3mz2vZI+lw3LgLSjh7+MI7DQBP4WpxCda5ito9wBW mY5J1rCHECjVInvx0Oj+WSUNCrcp4YtqRQFCIeuFzBZtULBc1GH9qf3soGvOya9TP3Ft dD4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770860584; x=1771465384; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pQNNV1lyjEdP2OrQfDb/AG8ogO9dTjL4vmNELjD2OdI=; b=W/FtRAs1LZwDOt26GbqUdN4k+QknTWJf21jImnOZwgYjLYEKan+kRZZTH/7YQkgVJy lSF0UviT8XN/1o0vFXa6cr9xmbFHgkmVd8JrYo8fd6mzOrQcvmwV6FU1lJ2LcSww/T8O /96pYOK/mh4f2bJ2OBdBZL0TxxhprkbA1Bx9DY060IlHuYh5lhOzLBx9nhAyjsgyRXa7 XrrYlruiyEwkEJl+q3tX4qXtC2QL/7lTnLXCoOavPQwuPeE0B28CT6vy3c4DG6w9AgjC 9gG8lOryllKajGCPO3hfYAg7ISs1OdtBKviOiGX23Rq/nu+y7Wd4pepDkl+Q/YZJvovd 1zbQ== X-Forwarded-Encrypted: i=1; AJvYcCVQHIZrQgnlgLw4J8S8yWskE1TrVn/rjzgbbWGNJRszaTD7ptItPRDaf2KCpjZG7fKXaE/4znzC/TF3uAM=@vger.kernel.org X-Gm-Message-State: AOJu0Yy73lTPJ+ONS/sVth5oPOAAWMRdbUtd9Nk730eDEHHdE9odNCbD DQqrdfAcoSazIZ0yNXyEnljEM2+FGuukaGwjZK99EfrJ+m8e24DzgrmUx+CkMRDAqvqwfC/MjDg jMHsHFc90hnPVjIdTYNEb6Vpd0heuOqs= X-Gm-Gg: AZuq6aLEgHUdar5uOskFNhB/NUWDjs7GorkoIdUOsLT9jN0VZnJyQj5hiOAPuGxPclS 7I0lITZVzL42P4KbxOO1fXNivgjH1FEYAtxHT0DuzQu7SmlCWRLYS5MZftVIdADUzgL50pp9vUi Z4DB2gasqsbIL0T7Y1O3P69v9eZH2th8+LcNn2Sa+CgM6fSC61P7R8IO7HvHCssnBeLebUblt3w X5fuke/aQvMegCWCZdAjGdUnG+HtYy7k+Tb4cv62EOHI/gJShrfBhBmFIdWM8zr6O8geOjzNeQ1 u6E2f1ZhYCjGmEupahs= X-Received: by 2002:a05:690e:190a:b0:64a:a578:9771 with SMTP id 956f58d0204a3-64be6baa377mr766642d50.26.1770860583893; Wed, 11 Feb 2026 17:43:03 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260210043456.2137482-1-haowenchao22@gmail.com> <5c4d773c-e3e7-4a71-b250-91701cbdd4a2@kernel.org> <52ab55c0-6b70-4afc-866d-dd505ff3e85b@arm.com> In-Reply-To: <52ab55c0-6b70-4afc-866d-dd505ff3e85b@arm.com> From: Wenchao Hao Date: Thu, 12 Feb 2026 09:42:52 +0800 X-Gm-Features: AZwV_QhWB8QKZLaQhjKHQWvchtvRzHYitwh0Jlcv9mT9NKSJgcevLLTvVJvIUZs Message-ID: Subject: Re: [RFC PATCH] mm: only set fault addrsss' access bit in do_anonymous_page To: Dev Jain 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2026 at 12:18=E2=80=AFPM Dev Jain wrote: > > > On 11/02/26 6:19 am, Wenchao Hao wrote: > > On Tue, Feb 10, 2026 at 5:07=E2=80=AFPM David Hildenbrand (Arm) > > wrote: > >> On 2/10/26 05:34, Wenchao Hao wrote: > >>> When do_anonymous_page() creates mappings for huge pages, it currentl= y 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 ca= nnot > >>> 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 introdu= ce > > some memory waste. I want to figure out the proportion of memory waste > > caused by large folios. Reading the "Referenced" field from /proc/pid/s= maps > > is a relatively low-cost method. > > > > Additionally, considering future hot/cold page identification, we aim t= o > > detect 64KB large folios where some pages are actually unaccessed and s= plit > > 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 wer= e > > 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 b= e > >> able to coalesce until all PTE bits are equal. > >> > >> This level of imprecision is to be expected with large folios that onl= y > >> have a single access+dirty bit. > >> > > Thanks a lot for the response. > > > > I saw this description in the ARM manual, =E2=80=9CD8.5.5 Use of the Co= ntiguous bit > > with hardware updates to the translation tables=E2=80=9D: > > > > > >> If hardware updates a translation table entry, and if the Contiguous b= it 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 sti= ll > > 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 acces= s and dirty flags of the PTE do not affect the transparent PTE coalescing function. > > > > The reason I have this confusion is that there is such a description in > > =E2=80=9CD8.7.1 The Contiguous bit:=E2=80=9D > > > >> Software is required to ensure that all of the adjacent translation ta= ble > >> 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 b= it. > > > >> -- > >> Cheers, > >> > >> David