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 BDAF63375CF for ; Fri, 20 Feb 2026 12:33:11 +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=1771590791; cv=none; b=EiJk64VlPgGjcNBzmk87r+8XPJQmDgiJOKBXEIVrC+Vl6Xf+GxP92P+b7ASS1Ik8I9eDHiWT0ehGABmACJoa1D4rLP4haEWBjRB09SQdjG9BqGjd3kTcX2PLC1qpyfW66v6sCyVa+uHfDuJJ4taD2LcDRGKQM16fb/jBP/9SBxY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771590791; c=relaxed/simple; bh=HEav6OKo9Ka2eLWNoeqr+fC5xj+AerMf/qZFR5ZgdYw=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UnaR3IQo8i8nU1k3cXAjOarajFBDtFLZTYObk1lqkPjIx1VWHB4iZin1y8s7SDmipUa2u5FTXlVdhw+SGHbIxijHAVsxDNhSNudULbg5gJoRfi8z6qy23JfFN830oEDnC5X8YL/iVOXrc4PGYYRtGYN488iB659WP3FAUD0n6vc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VOOjLrWN; 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="VOOjLrWN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CFF1C4AF0B; Fri, 20 Feb 2026 12:33:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771590791; bh=HEav6OKo9Ka2eLWNoeqr+fC5xj+AerMf/qZFR5ZgdYw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=VOOjLrWNvuLJ/gLuKzddCn1meEfv0f1LM/VWGLNgpdpvUZpc7/DBcH4tO33ee6GAf 8gOrynd24/1JtlWepOTFTCA/4J3E7Mh3Bisy072/WDcBw5sR9ML13CDJgYr8/Eg6+r I9wTZYmjIP0P6VNO4jDa0AcO8AXAI98hjNgX357a1U6VFSdNuWJt73UiOkt49A9Ip4 eVsevTdZTXdGuW5RL0F+mp4bBAKGoqxzufeTeYess2suL/1XVhfsskb8pDKcyK+VF1 wkGIucWNB2j68PoP9TB8fEDQ8uQ1qgdvdc0oal7Grmq+NDvBgx/Ykb0NGYfJbBnqmf wKh6JjuZ2arxA== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 558B3F4006A; Fri, 20 Feb 2026 07:33:09 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Fri, 20 Feb 2026 07:33:09 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdekgeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefmihhrhihlucfu hhhuthhsvghmrghuuceokhgrsheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpeejgedvhfeifefgleeuteekfeehfffgleegvdfgffehfeekgedtuefggfffjefgkeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkihhrih hllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeiudduiedvieehhedq vdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgsehshhhuthgvmhhovhdrnh grmhgvpdhnsggprhgtphhtthhopeefgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht oheplhhirghmrdhhohiflhgvthhtsehorhgrtghlvgdrtghomhdprhgtphhtthhopegurg hvvgdrhhgrnhhsvghnsehinhhtvghlrdgtohhmpdhrtghpthhtoheplhhsfhdqphgtsehl ihhsthhsrdhlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopehlih hnuhigqdhmmheskhhvrggtkhdrohhrghdprhgtphhtthhopeigkeeisehkvghrnhgvlhdr ohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlh drohhrghdprhgtphhtthhopegrkhhpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdho rhhgpdhrtghpthhtohepuggrvhhiugeskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepth hglhigsehlihhnuhhtrhhonhhigidruggv X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 20 Feb 2026 07:33:08 -0500 (EST) Date: Fri, 20 Feb 2026 12:33:06 +0000 From: Kiryl Shutsemau To: "Liam R. Howlett" , Dave Hansen , 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 , 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: <46817fe5-7166-4734-bad3-3109cc7feb1e@intel.com> 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 10:28:20PM -0500, Liam R. Howlett wrote: > * Kiryl Shutsemau [260219 17:05]: > > On Thu, Feb 19, 2026 at 09:08:57AM -0800, Dave Hansen wrote: > > > On 2/19/26 07:08, Kiryl Shutsemau wrote: > > > > - The order-0 page size cuts struct page overhead by a factor of 16. From > > > > ~1.6% of RAM to ~0.1%; > > > ... > > > But, it will mostly be getting better performance at the _cost_ of > > > consuming more RAM, not saving RAM. > > > > That's fair. > > > > The problem with struct page memory consumption is that it is static and > > cannot be reclaimed. You pay the struct page tax no matter what. > > > > Page cache rounding overhead can be large, but a motivated userspace can > > keep it under control by avoiding splitting a dataset into many small > > files. And this memory is reclaimable. > > > > But we are in reclaim a lot more these days. As I'm sure you are aware, > we are trying to maximize the resources (both cpu and ram) of any > machine powered on. Entering reclaim will consume the cpu time and will > affect other tasks. > > Especially with multiple workload machines, the tendency is to have a > primary focus with the lower desired work being killed, if necessary. > Reducing the overhead just means more secondary tasks, or a bigger > footprint of the ones already executing. > > Increasing the memory pressure will degrade the primary workload more > frequently, even if we recover enough to avoid OOMing the secondary. > > While in the struct page tax world, the secondary task would be killed > after a shorter (and less frequently executed) reclaim comes up short. > So, I would think that we would be degrading the primary workload in an > attempt to keep the secondary alive? Maybe I'm over-simplifying here? I am not sure I fully follow your point. Sizing tasks and scheduling tasks between machines is hard in general. I don't think the balance between struct page tax and page cache rounding overhead is going to be the primary factor. > Near the other end of the spectrum, we have chromebooks that are > constantly in reclaim, even with 4k pages. I guess these machines would > be destine to maintain the same page size they use today. That is, this > solution for the struct page tax is only useful if you have a lot of > memory. But then again, that's where the bookkeeping costs become hard > to take. Smaller machines are not target for 64k pages. They will not benefit from them. -- Kiryl Shutsemau / Kirill A. Shutemov