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 D24F4D3B999 for ; Tue, 26 Nov 2024 14:53:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71C366B0085; Tue, 26 Nov 2024 09:53:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CCCF6B0088; Tue, 26 Nov 2024 09:53:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 594076B008C; Tue, 26 Nov 2024 09:53:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3D1EC6B0085 for ; Tue, 26 Nov 2024 09:53:17 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ECC49C0AF2 for ; Tue, 26 Nov 2024 14:53:16 +0000 (UTC) X-FDA: 82828539150.14.F91D191 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 21D12C0007 for ; Tue, 26 Nov 2024 14:53:06 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.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=1732632792; a=rsa-sha256; cv=none; b=jGIZ1w44sUXwumWA9H+YHfcNwmBXJK4h8Vg2+hU+1X29eyyvxRrJBkhOAuGnbY+gIw5Gl7 e4R1RFPDGoX++X3BBWBG07t8iZtWSxLidKnaucBUnARrNWtenGCvQKsePnkW9lNL90f2Gv +5YKgSnuYDst1WGMrlcnUSqkAIzNj9Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.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=1732632792; 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=/24GaUEBcY1lL9TWCnsGnALktEbuvfxWyf3MCzYWY2I=; b=qXkBojVonOURZApEh2VZSCGQHz8fZXljtfaVVrdsbOabk/ngoG9Ubx4xi0AT/zHjNXrY0F ty6GkJ9Wp+KYm/fUioQiDyei6bEe3WQFQblRP9CixNz05TU6YCjwEhJQyLAiThhJ+IfeIU Dv0g+VlSDFKtktuGefOB1qznq2hTN6w= 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 1F046150C; Tue, 26 Nov 2024 06:53: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 2CB143F5A1; Tue, 26 Nov 2024 06:53:13 -0800 (PST) Message-ID: <69746c3a-72af-4c28-8f04-bcfae7a78107@arm.com> Date: Tue, 26 Nov 2024 14:53:11 +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> <7fb6c5a2-b9ae-4a29-a871-2f0bdc636e41@arm.com> <9675f4f0-6290-43aa-bf17-6b9c2b461485@suse.cz> From: Ryan Roberts In-Reply-To: <9675f4f0-6290-43aa-bf17-6b9c2b461485@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 21D12C0007 X-Stat-Signature: 956myk7fmd3u3swc1woidjapzdwnhhit X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732632786-452965 X-HE-Meta: U2FsdGVkX19xJHRQVimF19HYO1bgULR5SLEN5YKNBHHKUWrLrRna4y0J0B3lnstdb5Tog0KV1v3tfI5Hd60BmR9hz9AIppCjHBkCtNQ7v7OredHATABVaj28RGtHFZ6NJ71Yy4Y5ofpi7OkpOoNuNidKlp3kGr8/TwCfafESjDJewNL1/2zzfLxS9qllBK6cz8V7hGqO3pXaaRPXqPg8/Dad+lMs2hhAEsIcC0KhgFzSbAiWHgt/xAH5eWGFchMTX1Gwk/HmIRyY7kTpyuuTTI1uuwvo9gIhHPwz6awbBMw4HjSuqMt1DSnbJUDhChkf7VQVcv8gjpe8+gzOe7JVAnc2FhIKY7Q7FzcxiXovbXIHWm871e0HuFSVLo86Pk/cgoZzhfsi4j1m+7fooys02zpl+HfaXifhYXJ4hUNlJVJQsc9acHzmO8s7+XT458s8HGeGugzlFp42wNgbv4s+NrfC0d6oatnBSENF1AXg98mh8X1h4ul7Lr1SLu0wwcVjuXby3n/cLtZZbt7/Wir4EWNnNI9Mc1wfv0ch1wD2+9tQRX0roh97mRDDDGKaimxAmOVEMUXLXJ0t0Etg3eQsOJBOq0N7UPOIhvIih582mQ7FyVMILpbBDvmXg2RpESsM7OouNR5Ca6frCPAcehV1OjFvsfQjzZLHYVoy5QnZeEudzhwYtQqP3f/yr7EjX3Qyouyzh0g+IBy3HKHBC9U5u9KqA1JhpZ3Svppi4TsDwRMgn8zm9LsC8T1BgWFW8q/L0/X2rAPix4OI8ehDwfNsoanMDozUAXdptk3sgifgKNIw1VOKqGXgtEISFOnxOnzrG+6dxiffew7kXjGiCtxR4ezXTjbIXGEXFwQ+FBe0cce2NdYtXJz6D+9zqr2cnwHuZ82uiCvKK4hR3p6aBp4AW0uTFspizmUHHaQozBiI3VVlNuAaJ/erLQl8uisFzIiPShmNqKAgRIpuXQGF0hr UJ53fBNM JyNaGrcSNhE3x8IjQN3GFj62rUmSw4XRWixzGh7S5cfKqyPu5NdJBQLxAZAef91E+3uE3q6nsLKi3kMDi9XNcervWvjGb9xkgDSAtsR1r5rnypk1fJaivuYg5uFfVOdRPD77nuA7HkEU+JS+7JceiFEXvu+pa9b5hsC3P 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 26/11/2024 12:36, Vlastimil Babka wrote: > On 11/26/24 13:18, Ryan Roberts wrote: >> 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? > > Yes the e.g. 128k slabs themselves will be lazily allocated. There will be > some overhead with the management structures (struct kmem_cache etc) but > much smaller. > To be completely honest, some extra overhead might come to be when the slabs > are allocated ans later the user frees those allocations. kmalloc_large() > wwould return them immediately, while a regular kmem_cache will keep one or > more per cpu for reuse. But if that becomes a visible problem we can tune > those caches to discard slabs more aggressively. Sorry to keep pushing on this, now that I've actually looked at the code, I feel I have a slightly better understanding: void *kmalloc_noprof(size_t size, gfp_t flags) { if (__builtin_constant_p(size) && size) { if (size > KMALLOC_MAX_CACHE_SIZE) return __kmalloc_large_noprof(size, flags); <<< (1) index = kmalloc_index(size); return __kmalloc_cache_noprof(...); <<< (2) } return __kmalloc_noprof(size, flags); <<< (3) } So if size and KMALLOC_MAX_CACHE_SIZE are constant, we end up with this resolving either to a call to (1) or (2), decided at compile time. If KMALLOC_MAX_CACHE_SIZE is not constant, (1), (2) and the runtime conditional need to be kept in the function. But intuatively, I would have guessed that given the choice between the overhead of keeping that runtime conditional vs keeping per-cpu slab caches for extra sizes between 16K and 128K, then the runtime conditional would be preferable. I would guess that quite a bit of memory could get tied up in those caches? Why is your preference the opposite? What am I not understanding? > >> I'm happy to make this change if you're certain it's the right approach; please >> confirm. > > Yes it's much better option than breaking the build-time-constant part of > kmalloc_noprof(). > >>> >>> 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. > > Yeah as per above, should not be too large and we could tune it down if > necessary. > >> 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(); >>> >> >