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 268503F7E81 for ; Thu, 19 Mar 2026 16:56:20 +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=1773939384; cv=none; b=HTGhOIDVZSB4hOjA2RHlgnZRwPP9K5n8ONngL/9N7XX+NNlD78LsrM4OaUmDTjjc1i0ZYIMMqd+sv2qFnBKA5GEv5VuI85hqRtqZaMuEbkYFfpwk+kpRjHquHhJcGvURvkEvUXCZc9s3kvq/hC9I/yJX2fDQ0PeYyEETeyJGoMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773939384; c=relaxed/simple; bh=a5mEfj14oSM1tC7HNQl6vvgXT8KCSSJV/SG87pFz7A8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=G9cYSRk9GA1dy1MbvQditHSe23wPoua+YD8D4JnussDW6D01sXi4b4G3kB+rBqnfswKA7ZVlWa8MYOsTlJdhcjDYaT0z/K3g5Wk/imvXouZ6aTXRKWtpyChIl1Y6OeS5iCNknmlXL4abQbRzfaXY/x+7U5+0j8nPcJdZhKbudsw= 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=vQdBaC0Q; 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="vQdBaC0Q" 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=rCeA8gaapekYBXGTYyy6inc745Q+Z1LM+wKjknp8DGE=; b=vQdBaC0QVupOLntmdIDaZrn0Xg 121fyQDxZ+Dio6hLHiv7v9o+AE8SMLj30MEUKRC6o3LdExnLhUrL8RKRW2YRllz5pXo86pKjobU5q rjKmS51loCTwT24MKISGl1Ng/eisEvfF5XTDBCMozkrHN91kAO2dvlfOi07rsG8tCeimlHIN7aTWY jjEq4HW+DuyOs7HXJTeEexZq44JURy3AXG2knfOdokqjmSBETN5nA8AMNnaI3NZcwFGIB6o32rngC IoFGb6NwQ1M/G2ZnMXPPSEiXHPnE/4ZWguUPBcWk59L3J/E+h9lBWCIoh9qrdJ4rGnrpFbfB7XtGs 53mzPz8g==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3GfL-00000006Osb-1cvh; Thu, 19 Mar 2026 16:56:11 +0000 Date: Thu, 19 Mar 2026 16:56:11 +0000 From: Matthew Wilcox To: Brendan Jackman Cc: Andrew Morton , Michal Hocko , David Rientjes , Shakeel Butt , Vlastimil Babka , Suren Baghdasaryan , Johannes Weiner , Zi Yan , Harry Yoo , Hao Li , Christoph Lameter , Roman Gushchin , Uladzislau Rezki , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/5] mm: Switch gfp_t to unsigned long Message-ID: References: <20260319-gfp64-v1-0-2c73b8d42b7f@google.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: <20260319-gfp64-v1-0-2c73b8d42b7f@google.com> On Thu, Mar 19, 2026 at 04:03:23PM +0000, Brendan Jackman wrote: > As pointed out by Vlastimil in [0], my proposal for __GFP_UNMAPPED is > probably not needed for 32-bit. This offers a way out of the GFP flag > scarcity so in preparation for this, flip gfp_t to be 64-bit on 64-bit > machines, while leaving it 32-bit on 32-bit machines. Ugh. This grows struct xarray: struct xarray { spinlock_t xa_lock; /* private: The rest of the data structure is not to be used directly. */ gfp_t xa_flags; void __rcu * xa_head; }; which grows a lot of key data structures. It would probably have been good for you to have run pahole before/after this change and diff the results. Now, you're probably saying "But this makes no damn sense, why on earth is xa_flags of type gfp_t?" And the short answer is "because the radix tree has a ridiculous API". But you'll learn all about it with your new patch in this series which converts xa_flags from being gfp_t to a plain unsigned int ;-)