Received-SPF: pass (google.com: domain of linux-kernel+bounces-137578-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Zi Yan <ziy@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
 linux-doc@vger.kernel.org, cgroups@vger.kernel.org, linux-sh@vger.kernel.org,
 linux-trace-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
 Andrew Morton <akpm@linux-foundation.org>,
 Matthew Wilcox <willy@infradead.org>, Peter Xu <peterx@redhat.com>,
 Ryan Roberts <ryan.roberts@arm.com>, Yin Fengwei <fengwei.yin@intel.com>,
 Yang Shi <shy828301@gmail.com>, Jonathan Corbet <corbet@lwn.net>,
 Hugh Dickins <hughd@google.com>, Yoshinori Sato <ysato@users.sourceforge.jp>,
 Rich Felker <dalias@libc.org>,
 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
 Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>,
 Muchun Song <muchun.song@linux.dev>, Miaohe Lin <linmiaohe@huawei.com>,
 Naoya Horiguchi <naoya.horiguchi@nec.com>,
 Richard Chang <richardycc@google.com>
Subject: Re: [PATCH v1 04/18] mm: track mapcount of large folios in single
 value
Date: Tue, 09 Apr 2024 16:13:35 -0400
Message-ID: <1DFEC99F-6BCE-4E6D-9EF2-267E8A94A705@nvidia.com>
In-Reply-To: <20240409192301.907377-5-david@redhat.com>
References: <20240409192301.907377-1-david@redhat.com>
 <20240409192301.907377-5-david@redhat.com>
Content-Type: multipart/signed;
 boundary="=_MailMate_BEDB01A4-F93C-4BEA-B07C-1B36C5E3E053_=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?9FaQrJcpl757G7MAChdYV4rCY/0IifCZ/Uhgwt/qZmWaK1cse9a9l5JTkEr5?=
 =?us-ascii?Q?ixe2d5otq5Vgx58izMOn+13d2vAqBE/wQyPJNC8eNWL4s2iIXLRo6zaWhKHu?=
 =?us-ascii?Q?3CrEcBrTMu1lnmwLJhN8UHoK7SN/mfuzsVvgNAmymilYoyL8OLYL2cuwXfSg?=
 =?us-ascii?Q?Nrq88CZmzJI9mtZxt4z4UCuJt+Fb8cHa9zxaE2fg2TPYv+4EeB414nh31EW7?=
 =?us-ascii?Q?1h+UY+qUeI5XTF41ALk4Xt85VGZAoMO+UwT3tE8BkbvLJo4ch5HL9Vas+yC8?=
 =?us-ascii?Q?P2tlA7ZrpyfnynzcBDXU4BjKZypsWvwKIaCTlpbFqCwkRhvoxnj7H/r5SgKY?=
 =?us-ascii?Q?VzAO/qFym/NPpZVczHDXyivjxBcU5SvT1fARON7L5IdRu8hyioUQV+ESz35P?=
 =?us-ascii?Q?lQTpi+UQtdRjvo0EtG1iii7bRxtjF2ymCI4/0+SL2fMR4JdsVyUmXnC1z6ng?=
 =?us-ascii?Q?iFIYKrhAC8dWkHllkTi6kyBUv4wvx09eD1hQT+8Dp7Ks31xPu8RSPqtnDPil?=
 =?us-ascii?Q?Palx9nT4oJwolboyHZiFs3e/LZ6UbEqbmWPwGWlQxeH1q49lTQsMJPDGPlj2?=
 =?us-ascii?Q?kQtG6H0hbXABTN43zEmirXLqNfpanMuXYL3qwwiuFAgRPvLrrG76wIqR7cM6?=
 =?us-ascii?Q?rOQUawnvo5j1f6QybwRwvR0E86X1ef7LjBWV4rEeAOo7/pgA+py+N8n1RVTc?=
 =?us-ascii?Q?0R2RGtvoOkCFz3k5rcOh/o+NPqHtkrZiwfmO0noQ4Qgek34mR6MMx2GFif8F?=
 =?us-ascii?Q?0ZZ6+XDphw1f7e3umTJ+zIIPQXKhauxvLyZNv3x8nPLnTSAnBU0tNwvMnYoz?=
 =?us-ascii?Q?M+OjoTP54aS3M5tvGjl+7VDjolkC4GYXgpQmR3xu51hI6kqafWCUkj5PtGPc?=
 =?us-ascii?Q?sTf/OOYHbQ+6+EDUFGRwJC2FzBxofqd3QHyrop3Yuyrnznr3vRA0oPIXpP1S?=
 =?us-ascii?Q?+U2KWnKYqgzgtUXyM9XMtpyDsCDxnTWHIM/lsrijrYDNb25b3+RyHCpY664z?=
 =?us-ascii?Q?ZNYlUmqdDSI3I62kMgDOv/GYimt0+7bwaQTktC4EKVLfD05qv1qzesRx2st8?=
 =?us-ascii?Q?tvFrWxB+QLYI6IfEeI677wzOpKEntFxOtavemFV4M30d9zpdVBTZMkbHp0Mc?=
 =?us-ascii?Q?Kt/a+mpFt4E/O6E+hy0qjlRqtz+aF8g1QLzhUa7V4xDzMkc+oWGOOKaGpOJv?=
 =?us-ascii?Q?vQqCT3I5eu3Sekg1txy81WuL0sreJUwwoVrHpR2Z9w6vzbWQWok8h0V2g50M?=
 =?us-ascii?Q?C2LRldpkCqfMXbbssXmXVl3S18jBMOinJ8BGL2geLSqNLjTqZRzLa8M6sPfg?=
 =?us-ascii?Q?osO+TZ9porv+SDbiyktf8Zp08dON6QbbHtfAg3eUBpqt9qAyNs/ZPBAzEjMw?=
 =?us-ascii?Q?3OgN6AAWQtzcpLO/gL56SWYTOVuSH2GGnNxJzcsl7pkPBbt1PqjT10Ovl+W0?=
 =?us-ascii?Q?iz9rRCCkOoCcGSCSfhWgK2YmXBLZ0B8rHjFx5mUaenZPUW+sZ9tNbPJPVVn9?=
 =?us-ascii?Q?JmMF/3mbpCA/IU/CGbfFjD+rO+dj7YNNw8x0OMbQ8ctVG7y0h/LMmVgtNWn1?=
 =?us-ascii?Q?xCvbY2KD1T8RNyfpOWE=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0279c3b0-15fe-42bf-004f-08dc58d18aee
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB5744.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2024 20:13:38.3155
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: o60nxdNgny3CyCA2LbemLoJ8Vwc90fST6u0v7142k9iTvCQBwWs9MtnaCkgj99UE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7250

--=_MailMate_BEDB01A4-F93C-4BEA-B07C-1B36C5E3E053_=
Content-Type: text/plain

On 9 Apr 2024, at 15:22, David Hildenbrand wrote:

> Let's track the mapcount of large folios in a single value. The mapcount of
> a large folio currently corresponds to the sum of the entire mapcount and
> all page mapcounts.
>
> This sum is what we actually want to know in folio_mapcount() and it is
> also sufficient for implementing folio_mapped().
>
> With PTE-mapped THP becoming more important and more widely used, we want
> to avoid looping over all pages of a folio just to obtain the mapcount
> of large folios. The comment "In the common case, avoid the loop when no
> pages mapped by PTE" in folio_total_mapcount() does no longer hold for
> mTHP that are always mapped by PTE.
>
> Further, we are planning on using folio_mapcount() more
> frequently, and might even want to remove page mapcounts for large
> folios in some kernel configs. Therefore, allow for reading the mapcount of
> large folios efficiently and atomically without looping over any pages.
>
> Maintain the mapcount also for hugetlb pages for simplicity. Use the new
> mapcount to implement folio_mapcount() and folio_mapped(). Make
> page_mapped() simply call folio_mapped(). We can now get rid of
> folio_large_is_mapped().
>
> _nr_pages_mapped is now only used in rmap code and for debugging
> purposes. Keep folio_nr_pages_mapped() around, but document that its use
> should be limited to rmap internals and debugging purposes.
>
> This change implies one additional atomic add/sub whenever
> mapping/unmapping (parts of) a large folio.
>
> As we now batch RMAP operations for PTE-mapped THP during fork(),
> during unmap/zap, and when PTE-remapping a PMD-mapped THP, and we adjust
> the large mapcount for a PTE batch only once, the added overhead in the
> common case is small. Only when unmapping individual pages of a large folio
> (e.g., during COW), the overhead might be bigger in comparison, but it's
> essentially one additional atomic operation.
>
> Note that before the new mapcount would overflow, already our refcount
> would overflow: each mapping requires a folio reference. Extend the
> focumentation of folio_mapcount().

s/focumentation/documentation/  ;)

--
Best Regards,
Yan, Zi

--=_MailMate_BEDB01A4-F93C-4BEA-B07C-1B36C5E3E053_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE6rR4j8RuQ2XmaZol4n+egRQHKFQFAmYVoXAPHHppeUBudmlk
aWEuY29tAAoJEOJ/noEUByhUkTEP+wVZyjGvJVuk2NJsfh3tHj3THhkXQT6JLg4f
Z9ZEUxFY+Qi7f5ZNZtEt+B1Z98we+bRmjTBwplbnuU7gEUOe2s6yJy2INH1PV0LU
8bABPSURC+R1/F2lVj+2SAMk3Zwahv4YtsDfQrtCgcQpAXVXgyAoknMNewoUPy76
ZjwHSn7f0eg/CNCuSvr8usVjicaCkritgN/LFY93RylidI4ySjA0fWIkD9aQLtMI
ykZKxilaqW1PqmYHxDrUPQJpQMyrbnu1HWe6WFHpM+C2KRb7zdc4R+zDAvRwtw9B
Dn4aTB38JhsCCgO6pudcDLXb8UKe9UY5q4wzCtrtKi4qmduN+hxa9Sv7RNYA0AYM
TXaKTst8zlpXPw/dg/TJejbHepwRwmAYHqX0Ks5Nz4PocJv52kfwG4zm7eDFNmAq
4SU2kg9JrkJn5ysPmLTVOVKNd/b+I4ry2PEcAroJfIMkceT4XkPz6Qlb5eQ5/K8O
z2nY4sU7sm8a8hRMq5WrYaIyGoOaCx2mcXFvr1P/Tb0Di0wnCyB6skcp+Ct8lLqh
BaP0k9trLzItOdPYEO94hrBBxODkYb/kpPfmbRCS3S+ONZ44Ji7V4s+Wr+It+ydD
O/YZ8jEqwHJWHNbtiiNJ3D6iJ8EKA9+SaHs0Hyxbb3D9M+5DBeUgBG4m3k3ggR6f
mCcBQLZZ
=1QcW
-----END PGP SIGNATURE-----

--=_MailMate_BEDB01A4-F93C-4BEA-B07C-1B36C5E3E053_=--