From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ilvokhin.com (mail.ilvokhin.com [178.62.254.231]) (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 D536A3537F7 for ; Thu, 26 Mar 2026 18:04:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.62.254.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774548281; cv=none; b=ZjkHoEEc79N4zb3uB5Qtj8OSZtiVBxsAKo4TA3pdrLkDpI3hy6bgjyn7IHQ58kFOmCgnBHVkzM/s5N567qa0AWz5sl9KwYmiLdG8oG6xKdtuyMwtjfXUNm960ID51cU2Xg9FCKTruaPp+OaTCOmAmxJmEC2YucizZqyDkA6VtUc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774548281; c=relaxed/simple; bh=DqBJdr/hfb0BOI/5uiwFomlgK7snQAM6dybquS17hdY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CdlEmy1Ccubh3I+U8cS1JVlXQ11hYI7fptCWWj7yNMWRPhaYH840MpFxzR59L1TC4NruEPOi4l2AUR3L+OTNLg6VC/97NTzbVHn1sodLtxKYAzEWv5iOHW5w1LWHM/0rYcfVkjDZ7XZC/36ow421I+4YYdte9SYaKK5ZyS04/Tw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com; spf=pass smtp.mailfrom=ilvokhin.com; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b=t1v9tK/9; arc=none smtp.client-ip=178.62.254.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b="t1v9tK/9" Received: from shell.ilvokhin.com (shell.ilvokhin.com [138.68.190.75]) (Authenticated sender: d@ilvokhin.com) by mail.ilvokhin.com (Postfix) with ESMTPSA id CBBCFBDE69; Thu, 26 Mar 2026 18:04:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com; s=mail; t=1774548277; bh=ZQ89K3+y398sEmLbnjakuqThw5BZANxnbksEnP28xmg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=t1v9tK/94swMaUS3fnPB05FlcegFzlUOc917qnpf7c93a/ApEFIEGrj7S91rfWeI1 IFVl5fj2Lq/lXn2+R2+OXoywe4Rq6MLBG2GQskQTe42FW/ibqBPE5zEuuJrQ6/tKAN MuSutIbxMucS08vl9D8ABkaOJDii1X+oDCJD4Y5I= Date: Thu, 26 Mar 2026 18:04:35 +0000 From: Dmitry Ilvokhin To: Andrew Morton 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: References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> 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: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> 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. 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. 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.