From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4ACE02F5A06 for ; Thu, 19 Feb 2026 22:14:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771539267; cv=none; b=pzET/R4yyF8/N4YN5uoh3DAP5A9LmwNsVh9m/Vi0o0sxkOBiTGpv/lDVpoqSwgdhemXeuGUo7oxOqu3VsultGRlJU1s2+iR9GNFLDKe5oSZaWmsxGmAieiZmP2ppVXrsp/UDPEEQw0bPQB7zZkrHOWHhxasV5KTCoR8ppqVMosA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771539267; c=relaxed/simple; bh=Vh6icvfHV2ATgzeZ6D4jLG24kTd7OyiZdBtMQB7ol/E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RmqEAkvDAR02QVd0oTgM4V7Dhc7MgwdFglWNGvDF1X1IllVAVRz98DYxYGoMIm2kC1KclVh4v4FWbqx8/OVvr0SrCPM9PipDtubIeIZ5MBKszNmk9iXamZsu0wOdMewxXYAxYf8tdv83GkcJtughaUfhjRFJLhUW/T9/HtdlA5I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OY5FYxat; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OY5FYxat" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89851C19424; Thu, 19 Feb 2026 22:14:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771539266; bh=Vh6icvfHV2ATgzeZ6D4jLG24kTd7OyiZdBtMQB7ol/E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OY5FYxatv5zs2LVITb94C2qCXM4LYaYXaWHfcpxFgvtkRGz4aqUMNBE01ETPfrcZj 5LvBk7e9hoHNFTYY25fsTefQz1qQ6eghYD1hpoIF9I5I5EnB66A2/eJIVyq/oI8ALn C5A0yv1c80k/8tY3F/V5cJnOZOHUVcMYZb3ZGKJpjhaCzI2ExekCOCazozp0w3tgyO JlSp7GEe3NchAgPJKrJZyurNHKYlDt9TuyhTWSTOOy4IEaqn+yoOFpY/hv+OqF1/Qq yCTkNWmqiR7rAgOtXktgDuRbtHT8QnFGRE58eSjdXMNC42u0rNZ9Qc7c/I2LiCx/d3 VZi756ukMF0tw== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 7F47EF40068; Thu, 19 Feb 2026 17:14:25 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Thu, 19 Feb 2026 17:14:25 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdeijeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkrghssehkvghrnhgvlhdrohhrgheqnecuggftrfgrthhtvg hrnhepueeijeeiffekheeffffftdekleefleehhfefhfduheejhedvffeluedvudefgfek necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepkhhirh hilhhlodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieduudeivdeiheeh qddvkeeggeegjedvkedqkhgrsheppehkvghrnhgvlhdrohhrghesshhhuhhtvghmohhvrd hnrghmvgdpnhgspghrtghpthhtohepfeegpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegurghvvgdrhhgrnhhsvghnsehinhhtvghlrdgtohhmpdhrtghpthhtoheplhhsfh dqphgtsehlihhsthhsrdhlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphht thhopehlihhnuhigqdhmmheskhhvrggtkhdrohhrghdprhgtphhtthhopeigkeeisehkvg hrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhk vghrnhgvlhdrohhrghdprhgtphhtthhopegrkhhpmheslhhinhhugidqfhhouhhnuggrth hiohhnrdhorhhgpdhrtghpthhtohepuggrvhhiugeskhgvrhhnvghlrdhorhhgpdhrtghp thhtohepthhglhigsehlihhnuhhtrhhonhhigidruggvpdhrtghpthhtohepmhhinhhgoh esrhgvughhrghtrdgtohhm X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Feb 2026 17:14:23 -0500 (EST) Date: Thu, 19 Feb 2026 22:14:17 +0000 From: Kiryl Shutsemau To: Dave Hansen Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Matthew Wilcox , Johannes Weiner , Usama Arif Subject: Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86 Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Feb 19, 2026 at 09:30:36AM -0800, Dave Hansen wrote: > On 2/19/26 07:08, Kiryl Shutsemau wrote: > ... > > The patchset is large: > > > > 378 files changed, 3348 insertions(+), 3102 deletions(-) > > A few notes about the diffstats: > > $ git diff v6.17..HEAD arch/x86 | diffstat | tail -1 > 105 files changed, 874 insertions(+), 843 deletions(-) > $ git diff v6.17..HEAD mm | diffstat | tail -1 > 53 files changed, 1136 insertions(+), 1069 deletions(-) > > The vast, vast majority of this seems to be the renames. Stuff like: > > > - new = round_down(new, PAGE_SIZE); > > + new = round_down(new, PTE_SIZE); > > or even less worrying: > > > -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid); > > +int set_direct_map_valid_noflush(struct page *page, unsigned numpages, bool valid); > > That stuff obviously needs to be audited but it's far less concerning > than the logic changes. > > So just for review sanity, if you go forward with this, I'd very much > appreciate a strong separation of the purely mechanical bits from any > logic changes. That's the plan. That's the only way I can keep myself sane :P > > On x86, page tables are allocated from the buddy allocator and if PG_SIZE > > is greater than 4 KB, we need a way to pack multiple page tables into a > > single page. We could use the slab allocator for this, but it would > > require relocating the page-table metadata out of struct page. > > Others mentioned this, but I think this essentially gates what you are > doing behind a full tree conversion over to ptdescs. I have not followed ptdescs closely. Need to catch up. For PoC, I will just waste full order-0 page for page table. Packing is not required for correctness. > The most useful thing we can do with this series is look at it and > decide what _other_ things need to get done before the tree could > possibly go in that direction, like ptdesc or a the disambiguation > between PTE_SIZE and PG_SIZE that you've kicked off here. Right. -- Kiryl Shutsemau / Kirill A. Shutemov