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 8DFBB421A1B for ; Fri, 6 Mar 2026 18:25:02 +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=1772821502; cv=none; b=Yo96Zi8Vmpe6hdux5JdVjbDNkd/VxQCDHiY00F5mQ6Yqeq52yUmTMjnk96j/nKs4Suikgs8Xmcb9rPwLtOe4zGCc5Cxxg3npQwBPl8c8ujs+N5O9Qx1/K/3OtUDsVskeSZV2RTZc4BSxnslP+/NLS//xMh1RIYtofB8S6PgvQhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772821502; c=relaxed/simple; bh=1uq9z4/ibsX1WTmZECq30MMk5X7c41BLu0dsdJbzLvE=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=txdZVx2Z91GP46N8xqRMt0FkVSt+xPBpGe22hRMacOsqC8SwU4Ula98mAaKiJgtexAmM6sgOkdVfXNRwC+r3i5Dtg529f6VgqXCo8ZMo0RzUlnc2TKd29koyOJHqL0KwBIo02k46MLgPRZ4RF123A5texPGrF6mg7dwjEbWMvKQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tfK5QBJ7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tfK5QBJ7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1F1DC4CEF7; Fri, 6 Mar 2026 18:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772821502; bh=1uq9z4/ibsX1WTmZECq30MMk5X7c41BLu0dsdJbzLvE=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=tfK5QBJ7Ly5+nGF8m5oRBcOsYY4YQPlgbMZyXPT/Sy5R9XEvdzb/Yt00+6n+K1QAj arfzxw5dLDkTzgho+/gGrOaS35/5cO7ue4p0Zyer0FIgDGBfe9NMaB7xQJGmCQjWQr DdrS12z4fGzB588aXtYgq/Re3WU1aKw+ZKwzNbHvxrPslEhKbRMNaw7/jazbhEI029 00PVOU5NUzS/ZcusgWmGELcVY3bbB0I+JazrgyqybGM5lksJAhuCac9RUGe5yBjyUV C1rF6N2m8eD4waahoa0jqEKoEjSNfMzBhZYVchJEPelKuO46cEMTPqMTG1eUeZZrSV IPgDlRrvDBYLw== Message-ID: Date: Fri, 6 Mar 2026 19:24:56 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Vlastimil Babka Subject: Re: [PATCH 1/8] mm: use zone lock guard in reserve_highatomic_pageblock() To: Steven Rostedt , Andrew Morton Cc: 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 References: <20260306095336.a79fcc869a7f6d2b2e97501b@linux-foundation.org> <20260306130052.7da8eab3@gandalf.local.home> Content-Language: en-US In-Reply-To: <20260306130052.7da8eab3@gandalf.local.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/6/26 19:00, Steven Rostedt wrote: > > [ 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. I get this: Function old new delta get_page_from_freelist 6389 6452 +63 >> 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? 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. > -- Steve