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 51C5339DBF1 for ; Tue, 10 Mar 2026 12:57:15 +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=1773147436; cv=none; b=AHVfXYWHCG7B6a9RheGnJ9TtV3opvrvm7BEzaUPPkf5nCXzRFGSqkO7G30I/I7jfHEsjOYxfjyLJMQEr4R+90QcZcw8+4tQO9Q4ukO90RG3NZGOZp29oWzRHnWpXhanf2SCQSO5aKgLq9T4ZOEkObjTU9W5TX5U34EH711aau5k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773147436; c=relaxed/simple; bh=M3hr97Y+Ag3sEri/Sref0Md5FEaSRn9ccgyVPLb9Cc4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aZHCCqNY2kFhsKJAfdUtmjY/DW1pnWsRkVAJk0ki9iEkuss3QgE/ZaVZR3Pb1O/tj7Dn26+MAuEmpeycGoddKm/CwvUxTF8TeLuiyWg3oeITxRp6GZ5FjZCz0XG7FvRs54g7jwTX+CwNzICyZC8k5vbh07dyJ29rEwQcZ7fx1rw= 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=a2kd/i/Y; 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="a2kd/i/Y" 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 1B045B37E4; Tue, 10 Mar 2026 12:57:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com; s=mail; t=1773147433; bh=9Dsx/NIR1ZjMoRUA7M7tJHIHKo4GMgmcMyESER1ysIg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=a2kd/i/Yun5wM8r22ArXCh/GVja74SfYxQceck3++kZb7gzOLl32pLcBci+sQ2WWB drpUHLTxedU9rNPgGo/oSSrhQNC1Hj0HKfhkZTFc1m3bHCY5AMFyA2KNOfjPjMAuda Qze8HryB/aUeTNI9W25L3urO4X+cJLS4EasKHNzU= Date: Tue, 10 Mar 2026 12:57:11 +0000 From: Dmitry Ilvokhin To: Peter Zijlstra Cc: dan.j.williams@intel.com, Vlastimil Babka , Steven Rostedt , Andrew Morton , 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 Subject: Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock() Message-ID: References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> <20260306130052.7da8eab3@gandalf.local.home> <20260307131641.GX606826@noisy.programming.kicks-ass.net> <20260309164516.GE606826@noisy.programming.kicks-ass.net> 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: <20260309164516.GE606826@noisy.programming.kicks-ass.net> On Mon, Mar 09, 2026 at 05:45:16PM +0100, Peter Zijlstra wrote: > On Sat, Mar 07, 2026 at 02:09:41PM +0000, Dmitry Ilvokhin wrote: > > On Sat, Mar 07, 2026 at 02:16:41PM +0100, Peter Zijlstra wrote: > > > On Fri, Mar 06, 2026 at 07:24:56PM +0100, Vlastimil Babka wrote: > > > > > > > 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. In both cases imho worth looking into rather than > > > > rejecting the construct. > > > > > > I'd love to look into it, but I can't seem to apply these patches to > > > anything. > > > > > > By virtue of not actually having the patches, I had to resort to b4, and > > > I think the incantation is something like: > > > > > > b4 shazam cover.1772811429.git.d@ilvokhin.com > > > > > > but it doesn't want to apply to anything I have at hand. Specifically, I > > > tried Linus' tree and tip, which is most of what I have at hand. > > > > Thanks for taking a look, Peter. > > > > This series is based on mm-new and depends on my earlier patchset: > > > > https://lore.kernel.org/all/cover.1772206930.git.d@ilvokhin.com/ > > > > Those patches are currently only in Andrew's mm-new tree, so this series > > won't apply cleanly on Linus' tree or tip. > > > > It should apply on top of mm-new from: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > OK, so the big problem is __GUARD_IS_ERR(), and that came up before, but > while Linus told me how to fix it, he didn't actually like it very much: > > https://lore.kernel.org/all/20250513085001.GC25891@noisy.programming.kicks-ass.net/ Thanks for taking a look and digging into this. [...] > Anyway, if you all care about the size of things -- those tracepoints > consume *WAAY* more bytes than any of this. That's a fair point, but as I understand Andrew's main concern, the guard() usage becomes part of the code unconditionally, with no way to disable it, whereas tracepoints can be compiled out. Any overhead introduced by guards is therefore carried by all kernel builds. Given that, improvements to the guard infrastructure itself seem worth exploring regardless of whether this particular patchset ends up going in. If the overhead can be reduced or eliminated in the common case, it should make the trade-off much easier. Thanks again for investigating this and suggesting a possible approach.