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 6F93938F651 for ; Thu, 26 Mar 2026 18:51: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=1774551087; cv=none; b=AflNYb93Fv2nJb21UQ/Gz1Co+z8bTbBfvu+gsClPWJe3RiDMysgUCf63yCY2zYYVufqYRfJ29fnU85QIN+bd3YNpTI4Me3hy9AVcO4T28Saw0zzcAvP45fYmp99aUFsdkqCQm55X2oTNczWylNcG+7z5sB2Ezok1VYWTvM0CU+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774551087; c=relaxed/simple; bh=E1Bn4wE+ForM1okF61IbTJZ3NK6qA+FdoyLPEmf/rog=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=HyTbMUGVRcwITdT+RxlNI8vyc4n/6GnqwhkWkMrYbZbUowGFE3yRSQwp02O4oAss0Lm5lCqGagmQnXx5MF6KkGfDOXkz+xMVepYMWXtTTG4E5DDF7vKRgInklswPw6sZudhtNJitzcGKqKW0iGdzxduP0pFC3DatGWB2ZMJgSEs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=StWwL22U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="StWwL22U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F271C116C6; Thu, 26 Mar 2026 18:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774551087; bh=E1Bn4wE+ForM1okF61IbTJZ3NK6qA+FdoyLPEmf/rog=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=StWwL22UITgdBBiB2J/jv68HVdlnDIsFMjORJ9eGxANUdtpcHlfA7t6bQdoukkX90 Mn8FlN34p+FVWxTbFunsofh4fK0Rzh7iOfhLLslhGw+QPA8INtTHAQ/1Uel/V7OCeL db6V/clZQ2e5BH5orhrVEo44ZkO8PDTVhyAB0OqA= Date: Thu, 26 Mar 2026 11:51:25 -0700 From: Andrew Morton To: Dmitry Ilvokhin Cc: David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Steven Rostedt Subject: Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock() Message-Id: <20260326115125.923b6570bd18690897b82552@linux-foundation.org> In-Reply-To: References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 26 Mar 2026 18:04:35 +0000 Dmitry Ilvokhin wrote: > On Fri, Mar 06, 2026 at 09:53:36AM -0800, Andrew Morton wrote: > > On Fri, 6 Mar 2026 16:05:35 +0000 Dmitry Ilvokhin wrote: > > > > > Use the newly introduced zone_lock_irqsave lock guard in > > > reserve_highatomic_pageblock() to replace the explicit lock/unlock and > > > goto out_unlock pattern with automatic scope-based cleanup. > > > > > > ... > > > > > > - zone_lock_irqsave(zone, flags); > > > + guard(zone_lock_irqsave)(zone); > > > > guard() is cute, but this patch adds a little overhead - defconfig > > page_alloc.o text increases by 32 bytes, presumably all in > > reserve_highatomic_pageblock(). More instructions, larger cache > > footprint. > > > > So we're adding a little overhead to every user's Linux machine for all > > time. In return for which the developers get a little convenience and > > maintainability. > > > > Is it worth it? > > Hi Andrew, > > Before respinning this series, I wanted to check if it's worth pursuing. Probably. Much depends on the views of the people who regularly work on this code. Do they like guard(), or do they prefer the current explicit open-coded locking? > At the time you noted the text size increase and questioned whether the > trade-off makes sense. Since then, the guard infrastructure was fixed by > Peter, so the code generation situation has improved. Great. > The main benefit of the series is still simplifying control flow in > these functions (removing multiple unlock paths, gotos, etc.). > > Would you be open to this direction if the overhead is negligible, or > would you prefer to avoid this kind of transformation regardless? > > I can also limit the series to only the more complex cases if that > helps. Gee. I think it would be helpful to prepare a respin which reflects your current thinking, see what others think. Please understand that I'm resisting adding new material during this cycle (https://lkml.kernel.org/r/20260323202941.08ddf2b0411501cae801ab4c@linux-foundation.org) so you'd best be targeting 7.1-rc1 at the earliest. But sending out a new version during this cycle for people to consider would be a good step.