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 BE5D436DA01 for ; Fri, 6 Mar 2026 18:33:08 +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=1772821988; cv=none; b=iEBmoTwnI8BCQwM4ERIq39gkCot2XeB82y39hI+E353pBYUfU1mnkwRGwc0pWM/f0Ni8ybmNej2Je5YwddaSm+4b6aJjj+LX1+QHDGDL5uGV3xlm2K/wYSX4vTBFAtg1rEpSp3lx5NGHOUFn/Nrx0sjUCxkS2PgaWn934RMRv7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772821988; c=relaxed/simple; bh=ueF0lQCMqn4ypX+Y+YxYy+NgBlb2Rb7LtaIJJKGG2Fc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=pDfsN7iVR5adFLnVwhlwmsvwdol0fbd4lw2NgEcjeDZgDIiiZhyLRR+8Jp3/uw2S3dZEkjwRkYPtzAwYB6drh5lzzmsk9Cmr+C6EM3ocjGhj6PJn5nF6khzbAkzGmefUFkb1DPEjaKbyx9jPd9sqP65jPAQk/9vz9rxXXViDHuc= 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=KRsRIbXg; 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="KRsRIbXg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9337C4CEF7; Fri, 6 Mar 2026 18:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1772821988; bh=ueF0lQCMqn4ypX+Y+YxYy+NgBlb2Rb7LtaIJJKGG2Fc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KRsRIbXgs6VAkRPheR8mFFWeNSgVCVbf9AvoNcXeWNThs6FAcXlK4Gg9ApV+N6DHT rnDXR+En9MjFfx5wTXfawW+Onou99NAzYJuUyoeGK9fReMxYr8XkY7v2wCMZKV2SVi Rf4/rwGcPXAwY8i0hNd14n+XcPm7r+rsZQ3FZchA= Date: Fri, 6 Mar 2026 10:33:07 -0800 From: Andrew Morton To: Vlastimil Babka Cc: Steven Rostedt , Dmitry Ilvokhin , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , 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: <20260306103307.43d12be7d32b3f3b06f7bb55@linux-foundation.org> In-Reply-To: References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> <20260306130052.7da8eab3@gandalf.local.home> 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 Fri, 6 Mar 2026 19:24:56 +0100 Vlastimil Babka wrote: > >> > >> 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? > > Yeah I don't think the guard construct in this case should be doing anything > here that wouldn't allow the compiler to compile to the exactly same result > as before? Either there's some problem with the infra, or we're just victim > of compiler heuristics. Sure, it'd be good to figure this out. > In both cases imho worth looking into rather than > rejecting the construct. I'm not enjoying the ides of penalizing billions of machines all of the time in order to make life a little easier for the developers. Seems like a poor tradeoff.