Received-SPF: pass (google.com: domain of linux-kernel+bounces-186213-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 22 May 2024 09:23:55 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Xu <peterx@redhat.com>, Oscar Salvador <osalvador@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC PATCH v2 18/20] powerpc/64s: Use contiguous PMD/PUD instead
 of HUGEPD
Message-ID: <20240522122355.GR20229@nvidia.com>
References: <cover.1715971869.git.christophe.leroy@csgroup.eu>
 <ac9f4f2d6e571e4579a8125b81eaa88fbddd6187.1715971869.git.christophe.leroy@csgroup.eu>
 <D1EHK0STZ19E.3CTOAWG7LVBPK@gmail.com>
 <99575c2c-7840-4fa4-b84e-aaddc7fef4cb@csgroup.eu>
 <D1FRWM5DHHOT.3EAJGCLO0YTND@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D1FRWM5DHHOT.3EAJGCLO0YTND@gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?XBkxbeT3bK2bJRxyCyUyxkaqTeSvIG7NTuciD/T2em/Ovpp50pzInKGany4P?=
 =?us-ascii?Q?HUxhliH958NjjTU2I4uPjfrHBrJN9zsYUkAjKwRx1qhY93X67rBlV+ZQEaqA?=
 =?us-ascii?Q?C8+TL70/bDcJ5FDCDCix3KKh/jp0FYGaU4RUnwbDZtkzWHKSzYZjdAkUk2bY?=
 =?us-ascii?Q?Mm9dO5eTKsY7tBqs3DxNUpzTDYDbzCYU8boWPnd8CSCbHip+YLJSiRMh56Kn?=
 =?us-ascii?Q?aAjg8/A/s3Jr96Qs1q2ur3RsT475nHkWp4YKJ0WaFjJKM47VjTKO2FTC56aA?=
 =?us-ascii?Q?271vdZN7z/CzwhZTu0N1HiBU9UQxvwQ16Y3SYwFh9qXY7cnb+LMv4lLHT9qC?=
 =?us-ascii?Q?1e0e/ygZKp0MzMzSYLxSgbPRMjIDlll6S/0UTWTb1MECch0iNBGjpyqxnS0m?=
 =?us-ascii?Q?4szXaJItJrijx40tiWXoifI1HRKuOZKvHqDkqe98K9NtJhwqmb6SSD18wl/7?=
 =?us-ascii?Q?BGRdrJigOYG/W7eQ6cU90OzAAV8DX17tRxdpI7B3GhlLqfW8S7XaR4zLHJwx?=
 =?us-ascii?Q?G2qcjd3LIaZbNU3ripEyIw+tUtZwzhqSeouaku8OtzDirrdYPw5M71YvR41D?=
 =?us-ascii?Q?dxYkB626ntLU/kFqPXukbUS1LzjrsC9MgergJYOJSlx36MePxQRaFyEYXbgV?=
 =?us-ascii?Q?s5uLAL3ugsFGJuz05rsP8jJOP1GHfag/rzYiHRqAi1HYMmoC6Cbdrm2MizUd?=
 =?us-ascii?Q?pki6yLpb7aqtCmK+aSllcTN1RmBm/bGBdfmigMUGPCvV8x/Vt051JCvOqNz2?=
 =?us-ascii?Q?LrgIVPTsdcl6Rva1J4kSRSX7pVwyUl4kgdpzg/toFjJ9TUr2e4NSuG5f81FU?=
 =?us-ascii?Q?H6B+youwZzviVdsk5tCNL91wRExcZMK9pCOs40OsVzXqMi6/JcPRx/VsyYHB?=
 =?us-ascii?Q?agFcql53B0W/ymF1LiKVa/EBV+djEZQKWalJTHT+O86Oiiz0bKh+LOdt1Gnc?=
 =?us-ascii?Q?g0C2979ExVFmX5b1vTbwTy2yrMgRYNF5x41kZHL+FPDTq9TQZhJMlX5iCMvE?=
 =?us-ascii?Q?uuSuoDbK+A+EQqkS/5eWwswaVpnSHOU/aUXXjhGYpJAiILq92QqS977n0TCt?=
 =?us-ascii?Q?Qr+Ugya1eHSl+RhE8zZAEmha04b84d2DtAPc3nMqjyFt5cR/JvWFovN2KO4y?=
 =?us-ascii?Q?gCfaYw2aJ0bTFQmA50jKwkr1UhQAqdpurrsTOHIWZCAOAF0XvJt29Y+DQMYf?=
 =?us-ascii?Q?XHghMTkG/yHJZF66QazhvF8Bp7gJ5k/dgpRbWfdmO/2iV3TtPEqiHyo/JtTu?=
 =?us-ascii?Q?O2bSSVEzwudsOySVP8zHowv3+sZOn40RUzonFcxxMd8+MB3Ld8pfTJkVMoey?=
 =?us-ascii?Q?mXvZXsMDIN5ifoVN5un+RPF+0dS3p1Hwzrs07hSas5UTZZKE3zuxC4oQnXq0?=
 =?us-ascii?Q?7A9UhGzu5cWX3DxXbhCCecxJnaKrHkIS4csRYz99/qW3IPqFU/7sULQeKYW0?=
 =?us-ascii?Q?SErF67bTlbScq69Z+5Sxsioc7ZZujj9iP2XeTS/zOQIulzGozBZwR9X9NSFJ?=
 =?us-ascii?Q?+pieR7Vpnl1QSMzBPXhEuRF+93KfLe7mUofONSe4wDHbCHxXJQ1nNZ3q9o9X?=
 =?us-ascii?Q?DrkMwznC0fax6rPRKTE=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d1f563b5-f645-4f9d-249c-08dc7a5a0db6
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2024 12:23:57.6917
 (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: /UBVWUYyeYK8C6y5JcCkPWDqj+KX2FV/UJ5OnjxkaWxOK0rPrTYbNhtqsqvCb4nN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6915

On Wed, May 22, 2024 at 11:13:53AM +1000, Nicholas Piggin wrote:

> From the mm/ side of things, hugetlb page tables are always walked via
> the huge vma which knows the page size and could align address... I
> guess except for fast gup? Which should be read-only. So okay you do
> need to replicate huge ptes for fast gup at least. Any others?

We are trying to get away from this. We want all content in the page
table to be walkable via the normal pud/pmd/pte/etc functions and the
special huge VMA limited to only weird hugetlbfs internals. It should
not leak into the arch.

> There's going to need to be a little more to it. __hash_page_huge sets
> PTE accessed and dirty for example, so if we allow any PTE readers to
> check the non-0th pte we would have to do something about that.

Ryan added a special function to get the access and dirty flags from a
CONTIG PTE, the arch can do the right thing here. The case where there
was a CONTIG PTE that spanned two PMD entries might be some trouble
though.

> How do you deal with dirty/accessed bits for other subarchs?

ARM and RISCV verions will combine the access flags from every sub
pte. Their HW is allowed to set dirty/access bits on any PTE in a
contiguos set.

Jason