From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3D66BCCD182 for ; Mon, 6 Oct 2025 12:17:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:CC:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=c6qNB5bioMyGZXC3i2nj3ypKww+g+8GorxmNDFQZFEw=; b=EPT3x2mr53uIYNLjYjSMf0HOzZ Xmpyvc4BTrHjvzYFp+DKoTqGLjfUE6h5nBGZqccChtM3mIX1NcvbvTXJad1nf3oBRpurBvVHks6uH YG6lV0ThE2OdJ3XJOHif5GYQZPyrR3MKsrBKWQbKz/I1zUJtd91FyeF2N9YM6uPtIpm/cO/npnhnZ dSCOUMkzMjFCsvUlAWFD6fUIe5sdl08NLeJbnLEdcL+fof4cdiMVHYFsRutaVav09nYGtLsTwhBDx 0CZKvR5GzQXwIMjLeCm9PhF0qcFbOn7i0bDRoelYY+/gqQuROOwoEaOR70UhOiR6opIAbds1e8Uhq QDvyl3Eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1v5k9N-0000000Ha14-3lEX; Mon, 06 Oct 2025 12:17:09 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1v1W5H-00000003T1U-2OTL for linux-um@bombadil.infradead.org; Wed, 24 Sep 2025 20:27:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:Content-Transfer-Encoding :MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From: Sender:Reply-To:Content-ID:Content-Description; bh=c6qNB5bioMyGZXC3i2nj3ypKww+g+8GorxmNDFQZFEw=; b=d1Tsq7yUcgv69W1Ghppqpcds7I kzqS4tx8YNRLS7h5kl1l+bHVk0gM9a1mVsv1hzB+zsaL5I475PPrgO4uUGvrvUURyoRs2rciVl25y TzoCilO3AjgRJOM3vTh2Dzkn76P7kfGx9WuocETUrfB1yc4MXSXPGKIgfaC0JFHzosL1r5DinuRsv WgBMQDjKbL1eFzxo8cjYpaJUNLnAHaHYr87Pgq0PE3x7r20iq7+FVwUZW+Jhle03cDZLrOsNd8FWV xT35TKm3Xn5XIDXcySbA1+IIgkLFMHhdn1q2licg7jgPWPUdL57QVKx3QASqijh6wuaQgmijLWsjK cqD7ws8Q==; Received: from fra-out-011.esa.eu-central-1.outbound.mail-perimeter.amazon.com ([52.28.197.132]) by desiato.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1v1W59-00000008qcj-3hWc for linux-um@lists.infradead.org; Wed, 24 Sep 2025 20:27:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1758745639; x=1790281639; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=c6qNB5bioMyGZXC3i2nj3ypKww+g+8GorxmNDFQZFEw=; b=RKEizX4sYzjhrtdaTw1mKlS7vkqqh7MTd2Q1T9YqHO/KBxD1LVva5jJ4 RFstTWwT1SO4wCtmYBKEr8/cPVqCbO1rWqdqUKJsujhrrWNynwu4Hnoj8 sgZ2a5s1rm1GBpKoSasE+oXEMUS3FrlAl7bJNAxpt7au7AyjwA0Swllzy Ark0g2ZcZmJqTd+KoEJR+no9vsKB593L5BzsgrVVoqrh6EdeWlM2hJjb1 JYf92c8kTz11mVsQ2Yl+dNUlbNrNRptBWn4ix+b26+6/t/6tJU65c1Qn/ 8E13WQllTdK00+VOVFXRLZm9T9VTjUf8c+EbZuYy6vRm9x6jBRhIWyYLz Q==; X-CSE-ConnectionGUID: QHu5bLRcSKu84fbuw1a1Ag== X-CSE-MsgGUID: bgs/x27sRGSszuM/EX7RQw== X-IronPort-AV: E=Sophos;i="6.18,291,1751241600"; d="scan'208";a="2525964" Received: from ip-10-6-3-216.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.3.216]) by internal-fra-out-011.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Sep 2025 20:27:16 +0000 Received: from EX19MTAEUB002.ant.amazon.com [54.240.197.224:30691] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.9.61:2525] with esmtp (Farcaster) id cca380ed-bd19-4027-8da8-c940f126c2e4; Wed, 24 Sep 2025 20:27:16 +0000 (UTC) X-Farcaster-Flow-ID: cca380ed-bd19-4027-8da8-c940f126c2e4 Received: from EX19D018EUA004.ant.amazon.com (10.252.50.85) by EX19MTAEUB002.ant.amazon.com (10.252.51.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.20; Wed, 24 Sep 2025 20:27:10 +0000 Received: from dev-dsk-farbere-1a-46ecabed.eu-west-1.amazon.com (172.19.116.181) by EX19D018EUA004.ant.amazon.com (10.252.50.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.20; Wed, 24 Sep 2025 20:26:34 +0000 From: Eliav Farber To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: Linus Torvalds , Lorenzo Stoakes , David Laight Subject: [PATCH 05/19 v6.1.y] minmax: avoid overly complicated constant expressions in VM code Date: Wed, 24 Sep 2025 20:23:06 +0000 Message-ID: <20250924202320.32333-6-farbere@amazon.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20250924202320.32333-1-farbere@amazon.com> References: <20250924202320.32333-1-farbere@amazon.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.19.116.181] X-ClientProxiedBy: EX19D037UWB002.ant.amazon.com (10.13.138.121) To EX19D018EUA004.ant.amazon.com (10.252.50.85) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250924_212720_406038_72DCF361 X-CRM114-Status: GOOD ( 14.46 ) X-Mailman-Approved-At: Mon, 06 Oct 2025 05:16:28 -0700 X-BeenThere: linux-um@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+linux-um=archiver.kernel.org@lists.infradead.org From: Linus Torvalds [ Upstream commit 3a7e02c040b130b5545e4b115aada7bacd80a2b6 ] The minmax infrastructure is overkill for simple constants, and can cause huge expansions because those simple constants are then used by other things. For example, 'pageblock_order' is a core VM constant, but because it was implemented using 'min_t()' and all the type-checking that involves, it actually expanded to something like 2.5kB of preprocessor noise. And when that simple constant was then used inside other expansions: #define pageblock_nr_pages (1UL << pageblock_order) #define pageblock_start_pfn(pfn) ALIGN_DOWN((pfn), pageblock_nr_pages) and we then use that inside a 'max()' macro: case ISOLATE_SUCCESS: update_cached = false; last_migrated_pfn = max(cc->zone->zone_start_pfn, pageblock_start_pfn(cc->migrate_pfn - 1)); the end result was that one statement expanding to 253kB in size. There are probably other cases of this, but this one case certainly stood out. I've added 'MIN_T()' and 'MAX_T()' macros for this kind of "core simple constant with specific type" use. These macros skip the type checking, and as such need to be very sparingly used only for obvious cases that have active issues like this. Reported-by: Lorenzo Stoakes Link: https://lore.kernel.org/all/36aa2cad-1db1-4abf-8dd2-fb20484aabc3@lucifer.local/ Cc: David Laight Signed-off-by: Linus Torvalds Signed-off-by: Eliav Farber --- include/linux/minmax.h | 7 +++++++ include/linux/pageblock-flags.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/include/linux/minmax.h b/include/linux/minmax.h index 2ec559284a9f..a7ef65f78933 100644 --- a/include/linux/minmax.h +++ b/include/linux/minmax.h @@ -270,4 +270,11 @@ static inline bool in_range32(u32 val, u32 start, u32 len) #define swap(a, b) \ do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0) +/* + * Use these carefully: no type checking, and uses the arguments + * multiple times. Use for obvious constants only. + */ +#define MIN_T(type,a,b) __cmp(min,(type)(a),(type)(b)) +#define MAX_T(type,a,b) __cmp(max,(type)(a),(type)(b)) + #endif /* _LINUX_MINMAX_H */ diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h index 5f1ae07d724b..ccec17a67af8 100644 --- a/include/linux/pageblock-flags.h +++ b/include/linux/pageblock-flags.h @@ -41,7 +41,7 @@ extern unsigned int pageblock_order; * Huge pages are a constant size, but don't exceed the maximum allocation * granularity. */ -#define pageblock_order min_t(unsigned int, HUGETLB_PAGE_ORDER, MAX_ORDER - 1) +#define pageblock_order MIN_T(unsigned int, HUGETLB_PAGE_ORDER, MAX_ORDER - 1) #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */ -- 2.47.3