From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) (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 0ED58140E5F for ; Fri, 6 Mar 2026 18:00:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772820059; cv=none; b=ik9kGjf8fnvEtIndVQEZYxt0cPSQKE2nT5WI4D6zLGYDq0+CoYYGYJFyqBO1M2XkrnYMnva28v2/J9Ht1KyN/hD+EdQO5gqPt1/rYleGnfjHwy4otR4zu00mAR6CmGangIKbn+jPbFP7BRpLw/wl9I/uGt7yB5DZzlU9x3LFBfg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772820059; c=relaxed/simple; bh=pTivFrHYzonbSL+vtQsw4/q/ajfDBxnmw8Vb1vNMmrc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=n1Hrn+m77/Rqhi2YFo2H0Ocqlby0ArEWx9XGfltCAKdtZMRhYpriG4eyt/Ac92HB+jFM2DSyfeXhp7kK5Vfs0n+PqYG51yegSN/LVVqvZdDyKA4syy6zznVlNps7Sc2EwuP7BpJkogL+W6z/JRQhFT2sOO996kArC2sTaS2IOwE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 837631B85AE; Fri, 6 Mar 2026 18:00:55 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf11.hostedemail.com (Postfix) with ESMTPA id 048F22002F; Fri, 6 Mar 2026 18:00:51 +0000 (UTC) Date: Fri, 6 Mar 2026 13:00:52 -0500 From: Steven Rostedt To: Andrew Morton Cc: Dmitry Ilvokhin , 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, Peter Zijlstra Subject: Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock() Message-ID: <20260306130052.7da8eab3@gandalf.local.home> In-Reply-To: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> X-Mailer: Claws Mail 3.20.0git84 (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 X-Stat-Signature: azbz3i7fut6j7gnz3cktc9cc49bbdmc9 X-Rspamd-Server: rspamout04 X-Rspamd-Queue-Id: 048F22002F X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/6Ow7aF6DmQhdrW9kJih2ck9+OIyCBH/U= X-HE-Tag: 1772820051-753140 X-HE-Meta: U2FsdGVkX1+PCmMBt+lClgi6UsFpx96YSReA/s0JN4Fg9contLIxr2iGTktY9FD2H68DBV2ce4rR1eDF453v/D4BqPnYbBmgcbAAcqONfI9XKJ0aQ+AEZYEg/fgJkb886L3MfEqbUO/SO0gCsqukCvlRh+GqR6mgrhqS/wNVBF4AIopBFgu9itqpy8C236rhTyL7WYJuaVNmHsl3n5mMwJ3kQ3kZPjZGdSkzrY7MvcfOUL8jikJpao9sBW8cJEMnLBd0vsoViWDcrZQjSnmo1D5/Jd2yOp1lpj6Nd2gckQKQnJt9LbXr1w8VkY/tc8Ta330P/qc2uKmE0jN0krbrQwgZYSH3KUtHHDOWpflUOB6hu++YFbg1he7OjW9WNg9njSrH6es4ThqGFYLIB8XeAPMF/IKSpQxLrK9OgJdl76k3yf4KohOdqvH1beBGSize [ Adding Peter ] On Fri, 6 Mar 2026 09:53:36 -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. I think maintainability is of importance. Is there any measurable slowdown? Or are we only worried about the text size increase? > > Is it worth it? This is being done all over the kernel. Perhaps we should look at ways to make the generic infrastructure more performant? -- Steve