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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 072FED3B989 for ; Tue, 26 Nov 2024 12:18:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C0646B0083; Tue, 26 Nov 2024 07:18:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 370676B0085; Tue, 26 Nov 2024 07:18:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25EDE6B0088; Tue, 26 Nov 2024 07:18:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 083CC6B0083 for ; Tue, 26 Nov 2024 07:18:18 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6CE14A0C2B for ; Tue, 26 Nov 2024 12:18:17 +0000 (UTC) X-FDA: 82828148424.19.7D381EE Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 387B61C0012 for ; Tue, 26 Nov 2024 12:18:07 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732623492; a=rsa-sha256; cv=none; b=OzoHX7b/YxfDJ3bUK8MOeT5Khr0h1L/mNNbxnDkx/K0PNU5+51OFykdmQazjuh53+ChDem 4hd+AO4l3gnmrf/B+vnsNGfZZgiSF2glOMqppbYlYg8sCEbPuvSEj4MRHQSYPy/4m+eHIu UtzCK+d4D0zgeYa9E1xt+nRLpEPYcVU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732623492; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v4jvvkZ90+d6neI24dv6L5kYRfM8SVNb8gQBDPwg6w4=; b=VW5/4Tu2O1+5oGDoBEFAUwZAKDIfpPd1pJS8wskFiTKzEwXNSpSDwLJJ5AykubL7CSpSSX sSZppc+r/KFAZtFLjR9GOPAe2ZnK3xaXvyUZKLuvrT+0L1ueJmBWWg+U8Z/3xlK19iZIlt IyFD+tgZVSK05jTY6DaTCg7YWn8zoIY= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A889F153B; Tue, 26 Nov 2024 04:18:44 -0800 (PST) Received: from [10.1.29.199] (XHFQ2J9959.cambridge.arm.com [10.1.29.199]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B6E433F58B; Tue, 26 Nov 2024 04:18:13 -0800 (PST) Message-ID: <7fb6c5a2-b9ae-4a29-a871-2f0bdc636e41@arm.com> Date: Tue, 26 Nov 2024 12:18:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm/slab: Avoid build bug for calls to kmalloc with a large constant Content-Language: en-GB To: Vlastimil Babka , Dave Kleikamp , Andrew Morton Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20241014105514.3206191-1-ryan.roberts@arm.com> <20241014105912.3207374-1-ryan.roberts@arm.com> <20241014105912.3207374-6-ryan.roberts@arm.com> <44312f4a-8b9c-49ce-9277-5873a94ca1bb@oracle.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 387B61C0012 X-Stat-Signature: 4w3b19k3tj158j7p4qbgqjbpb7ymtdcq X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732623487-395875 X-HE-Meta: U2FsdGVkX18qbmx7FjipGE1NyQvUGG68UyN0gezQ7ddIwUhjhKMx4D2aqIpX0z89/F9WXbvBPDP1t0YeNd79lzw4FVXG3fh+ua1zopXaH7Qu8BSCYpJbdCU7SR6eVzDq114twjfc2sOfVSS8RzLj5Boy+6nF0jvTHFrvqJmn0l5YCdRzgeWX69bUpUIFEqGYrWimXgjvbIfv9PN/WmK6RKFTdacaH9tiHxBcejAD/uOYQ95Un5UhcUIwmgJRWI+VJDSczYldfDwhhB9/Th5bjcnyT/nv5wnhf44PRxlVRwSM2apEHbyoXJoNRv0TzAhaRgSA3k7Lu5Q+B3TRToL1B4vlwnmebM6EpEkK18769Q+xatVNununHhPaO8qSp4JbtCkBL8BIsyJGjeZEoy8EVzTetnMIVWNLRZW777NIsIT3dZR62sM7ihQ/dQoaSYw5Wqqrzq38/vjSSndxcBTN5UO00xMz8RkyMlFGY+ROC6rfPDY0K0LvDH+cLDTKDpo8pTZlAcX0XpPqrMwcsLQqYQIs7KeeHInzIOHlZpif8sYJc2hl1pJsPMn2qEiqB2xF7Mv5UJ/mnQhwDRg55miKW7xgtooCEl+jVJMwbLEp6mD36z4tvx/P+2mNuqc0P5zocp2R4kU1QEaJxpTac2fDfn8fzR1PopJ7N8FqEWAR4ORe+sIprHE2TMepvH1ZxnqEq5QBD/i3mOf6/JxfcC+L/KLeNSBiHGe6tbkAXKZt0oWrZQBZgwceLduWtLAtiR6zzFi7i4dE2FuVBmWgz0h3sSlqrEdWfSYlQoTrlsKPCpOiQUkJIw4a/poWY07kFkovYNhZ2G5jnNggwp2y6RKfgLrpSPyjRj8bETIEswAOpXuz4l7wyvckB91hLRVKVleJktvCpBP9i2DTqKNhqkJkJno8MYSZYyjfsPNKQDVIfQucfwoPfcDvZ/gy8AoTNJoFdocbaz2chEiTdGXty3x r5/H6pLb WkhM6XpWcUW42hJVb6ZXH6CVM6Uy0D4wjUDdC+DmZS0NomWBzHyFxPMU+5aGdNhPAp1o3530jPlFJUuPrCMRfwGRE1n4jMcUNL+iKCtu1OWDbIF1gP0awmcxeB0uoTyDaJVqZhxk4nLJppvpfzlwf9rOKYuDB9C5IQuGx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 14/11/2024 10:09, Vlastimil Babka wrote: > On 11/1/24 21:16, Dave Kleikamp wrote: >> When boot-time page size is enabled, the test against KMALLOC_MAX_CACHE_SIZE >> is no longer optimized out with a constant size, so a build bug may >> occur on a path that won't be reached. > > That's rather unfortunate, the __builtin_constant_p(size) part of > kmalloc_noprof() really expects things to resolve at compile time and it > would be better to keep it that way. > > I think it would be better if we based KMALLOC_MAX_CACHE_SIZE itself on > PAGE_SHIFT_MAX and kept it constant, instead of introducing > KMALLOC_SHIFT_HIGH_MAX only for some sanity checks. > > So if the kernel was built to support 4k to 64k, but booted as 4k, it would > still create and use kmalloc caches up to 128k. SLUB should handle that fine > (if not, please report it :) So when PAGE_SIZE_MAX=64K and PAGE_SIZE=4K, kmalloc will support up to 128K whereas before it only supported up to 8K. I was trying to avoid that since I assumed that would be costly in terms of extra memory allocated for those higher order buckets that will never be used. But I have no idea how SLUB works in practice. Perhaps memory for the cache is only lazily allocated so we won't see an issue in practice? I'm happy to make this change if you're certain it's the right approach; please confirm. > > Maybe we could also stop adding + 1 to PAGE_SHIFT_MAX if it's >=64k, so the > cache size is max 64k and not 128k but that should be probably evaluated > separately from this series. I'm inferring from this that perhaps there is a memory cost with having the higher orders defined but unused. Thanks, Ryan > > Vlastimil > >> Found compiling drivers/net/ethernet/qlogic/qed/qed_sriov.c >> >> Signed-off-by: Dave Kleikamp >> --- >> >> Ryan, >> >> Please consider incorporating this fix or something similar into your >> mm patch in the boot-time pages size patches. >> >> include/linux/slab.h | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/slab.h b/include/linux/slab.h >> index 9848296ca6ba..a4c7507ab8ec 100644 >> --- a/include/linux/slab.h >> +++ b/include/linux/slab.h >> @@ -685,7 +685,8 @@ static __always_inline unsigned int __kmalloc_index(size_t size, >> if (size <= 1024 * 1024) return 20; >> if (size <= 2 * 1024 * 1024) return 21; >> >> - if (!IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) >> + if (!IS_ENABLED(CONFIG_ARM64_BOOT_TIME_PAGE_SIZE) && >> + !IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant) >> BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()"); >> else >> BUG(); >