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 EC8E62BF00A for ; Fri, 20 Feb 2026 15:50:13 +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=1771602614; cv=none; b=SIra+8eDTDpMh4mbQ05RRz+G2cORAumouWl7iNJxSicFc7AGDa5BUdtGdEkzj7DrBCXYhU5+ZZf+qk+hJkqh9Rk++T4gpenB2zN3pq/ma7fts+Gz4XVT+QkqLJS6kfDlxKE1Fnf4/h3L7YYExZSntE5zIuoYZk1arRY37GLrmmA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771602614; c=relaxed/simple; bh=7gaP1GdZI+M5LlRMzEn27CMVU3D0Uf3Bl1Suhpy/K90=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sGgWtP47XyMRQmsmGEK3mVd7mc+DYcNl3wkkIuq2JBcHZK8iK8mOZ3yRhyz/FAfaS++eWtoidCxO7sC8qQ/XHQW0XRe94oZwvZ5ka5KMkbjIBK3wY8EuGxCZ9SGubCg4dwuW2vtrMy+oNglDUONUXK6ESdNTVy/j26GDYKNNjPs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tloJ8Ohu; 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="tloJ8Ohu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D132C19425; Fri, 20 Feb 2026 15:50:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771602613; bh=7gaP1GdZI+M5LlRMzEn27CMVU3D0Uf3Bl1Suhpy/K90=; h=Date:From:To:Subject:References:In-Reply-To:From; b=tloJ8Ohu+xd4bAMtoqr3DTb8/2NB0md5p7Amg3ftE7ddTZyEPRxOY7S2KuYP0WgsI y4j9PC8pllX9Ki9xbM8QIV6d0D+EVb7nvqU8T/i5lgy69r6QsbmvrxoYqNQ+jeCFfs Rcawl8pRH4NcxFfN4HuvnaJX4pvvW620m4ORtFODKN3a3qj+YQ5n9e7wPkHQ2rvQso goTNiugfcHOcMCgWmU4AteGLMiNF/u7u3MksLTGlHA3+L20ADPRKCf7ExxDeBgCTCg WDro6bpfN2g81C/IN09THxuQaVry8/GwmdAmMEA9VDBZ3AuL3BkPmJ1aYGVsfz3gLA 5XQGuHefb+hkw== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.phl.internal (Postfix) with ESMTP id 6FA0BF40068; Fri, 20 Feb 2026 10:50:12 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Fri, 20 Feb 2026 10:50:12 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdekkeegucetufdoteggodetrf 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 10:50:10 -0500 (EST) Date: Fri, 20 Feb 2026 15:50:03 +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 Fri, Feb 20, 2026 at 10:17:45AM -0500, Liam R. Howlett wrote: > * Kiryl Shutsemau [260220 07:33]: > > 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. > > I think there are more trade offs than what you listed. It's still > probably worth doing, but I wanted to know if you though that this would > cause us to spend more time in reclaim, which seems to be implied above. > So, another trade-off might be all the reclaim penalty being paid more > frequently? I am not sure. Kernel would need to do less work in reclaim per unit of memory. Depending on workloads you might see less allocation events and therefore less frequent reclaim. It's all too hand-wavy at the stage. -- Kiryl Shutsemau / Kirill A. Shutemov