From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 BDE1C38F94F; Wed, 25 Feb 2026 16:04:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772035443; cv=none; b=dlrpbcCod4k9PVOoIjR1cc1lTkcWi8m9Zx1V1wKkKzJL7c3RT7hmlREUyS6uvqEeSJKNQV2JwyQSnGLcnIvPfTyUv2sIibsRATKiBNmDiAyL827bgwNg1SZLnpIvaTgmaeOQjuvWwNKOkSIX2EsMkOuVzvE3s2TKZMG2CcQlOu0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772035443; c=relaxed/simple; bh=rFT2UsvGLAUGUVK5ZLvPz+k6h+sdXuLVoLa/dlc4oCY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GrsV/aUkxVI8NULJgJNppqSmOVcJhnbKQTqXExM/5c3N0JvSBAR8keCTa6eA1cfKg8fzHfoX4WgiblUcbYtNvvtH2iOR7dvbInxMptdoxPK4d0VSAw+QDZSDcs+yeHWP902g0V47JjDSBc0vnQGU4rNNS4gSbv4qE5fDyVb47Pg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=dj9Dk53q; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dj9Dk53q" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=0J9g8glZ+C9CG7kUr9i2GkA6jzB/Q/+QP9Ox+/ZoIEo=; b=dj9Dk53qD1T3gEZZjGN45q0fZD rQKifH55s16xa+rDffcwJr9feocDEB0brkJJxpJwJgJQ9uv9xFTbIPNpSTgDz+lEWJHXEPyVJC7nD Y2DD3D+KwdFRDllP8yehqZYVfq2nIVjT4R9wLmXdivXqDf6olo23/DmmW42AVwx//Bs4pk3iPQ4qq vhk+23SLbevluYXNxnWvXg/TVqyScR8gOXssjFU/rG3rP8QtQtriv5rst9CbUvCK2I7r8MrLvYWHH bqsXwasdupeD2FfwhB3yeJ9LKc9Prz2LUsLCTRSa40+Ui9Q7jx+fTtBLfAUpPN1moyrGTMpNyeoZH N4lDa15w==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvHMg-00000001Icb-2aQy; Wed, 25 Feb 2026 16:03:54 +0000 Date: Wed, 25 Feb 2026 16:03:54 +0000 From: Matthew Wilcox To: Axel Rasmussen Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] Revert "ptdesc: remove references to folios from __pagetable_ctor() and pagetable_dtor()" Message-ID: References: <20260225002434.2953895-1-axelrasmussen@google.com> Precedence: bulk X-Mailing-List: stable@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: <20260225002434.2953895-1-axelrasmussen@google.com> On Tue, Feb 24, 2026 at 04:24:34PM -0800, Axel Rasmussen wrote: > This change swapped out mod_node_page_state for lruvec_stat_add_folio. > But, these two APIs are not interchangeable: the lruvec version also > increments memcg stats, in addition to "global" pgdat stats. > > So after this change, the "pagetables" memcg stat in memory.stat always > yields "0", which is a userspace visible regression. > > I tried to look for a refactor where we add a variant of > lruvec_stat_mod_folio which takes a pgdat and a memcg instead of a > folio, to try to adhere to the spirit of the original patch. But at the > end of the day this just means we have to call > folio_memcg(ptdesc_folio(ptdesc)) anyway, which doesn't really > accomplish much. Thank you! I hadn't been able to get a straight answer on this before. You're right that there's no good function to call, but that just means we need to make one. The principle here is that (eventually) different memdescs don't need to know about each other. Obviously we're not there yet, but we can start disentangling them by not casting ptdescs back to folios (even though they're created that way). Here's three patches smooshed together; I have them separately and I'll post them soon.