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 DD392C4829A for ; Mon, 12 Feb 2024 02:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4791C6B0074; Sun, 11 Feb 2024 21:07:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4299F6B0075; Sun, 11 Feb 2024 21:07:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3180A6B0078; Sun, 11 Feb 2024 21:07:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1F49D6B0074 for ; Sun, 11 Feb 2024 21:07:04 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B9B53A0920 for ; Mon, 12 Feb 2024 02:07:03 +0000 (UTC) X-FDA: 81781513926.24.B1C29FE Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf11.hostedemail.com (Postfix) with ESMTP id EE7874000E for ; Mon, 12 Feb 2024 02:07:01 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf11.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707703622; 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=q9VC+jysHWb4ROuUk6l0Vf5RblxE4afMpSdbrGxgoz0=; b=q4fIuo2oL30dkMhkOmpBQV//Iiz5Spts968ejx0/90XJHVwah2nxzTsXXu9bBxT2+kf8L1 I2PrZMF5dPaY1k8fwS9EzJyHo3sQZbA3xWJQE/GR4s0xZQAu5oDp4PlOrVoEIeg4LFz2Up f2Ea81+yA0DigRQArQNeHoKgU7vf78w= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf11.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707703622; a=rsa-sha256; cv=none; b=QnMbBTGCM2abXBhsQziFfHnpzBa+dpy01frigP9k8vkBJrAwNovfpTXTQih0kKICQ/HkXS PoCs+NN790mzM0k1wE9g6Gc+ZNHmM4LFB+mIMh+9Euk4ZkJQPcdtPLJJNHDcSfdYyuWZr9 4CtrjKN3tNiAsiS+yI+SuJJZz2/WvO0= 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 6CB6DDA7; Sun, 11 Feb 2024 18:07:42 -0800 (PST) Received: from [10.162.40.23] (unknown [10.162.40.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B76123F762; Sun, 11 Feb 2024 18:06:59 -0800 (PST) Message-ID: <559e213a-bd39-4799-8899-c8689e09a01b@arm.com> Date: Mon, 12 Feb 2024 07:36:56 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Anshuman Khandual Subject: Re: [PATCH] mm/hugetlb: Ensure adequate CMA areas available for hugetlb_cma[] To: Andrew Morton Cc: linux-mm@kvack.org, Muchun Song , linux-kernel@vger.kernel.org References: <20240209065036.1412670-1-anshuman.khandual@arm.com> <20240209141637.129e417747ef130255db620d@linux-foundation.org> Content-Language: en-US In-Reply-To: <20240209141637.129e417747ef130255db620d@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: EE7874000E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: b6mztjti379br9a4qtix8kg68pf7tij8 X-HE-Tag: 1707703621-18022 X-HE-Meta: U2FsdGVkX1+Q4QPy1bW2RVmGAMmjfyUAQiOAw4UaHMoLNDz5bTlUnvrlrwYOSN7qDQkOwvyHl06jeiisjYwqAhY3Myx43iRg1XnBGAuNnIz0d8F0xDnp3aulefOr41dRlEigaGTVFpkBKPEjapRVbTtk1QPGa9XCr6QCPqmxHN3pSD1V+mrHYkHpkHhxunQ0rOvL2uEhvQa5BEql9J0atKkk+KL9bc3rbwQ3XfeEtF+s1ZoNm0FUGyJ2FoVlB3CRzGW6cR0wvsKnMq3jWbeiWO8L6lDOA/t7Ia6AkCLdbSAxKFQQjsL3XZkIAVd73InZ8gThnYyxho7FrdbvofFb4YvjuehwUHCIDJzQkVUkTjfPxrPzLSA8M4v/zu1GuVvH00gJkuqm2JfdSODMhKhTruwL5x6AgAp+Hke+GZ22SCiNKsruEVKnAgTLNfOQ7hjjHWxxWk/EYUHz9DzHapjZGDRWPqBvw4Aakqm5ZETeROUxE5Rt2b9U22CkXASuTJuDVrAuDpqxf4V9ApDtefd8nrlo2bQAcN/AGjfqyxgGsfGLibU7VdjszLKmRSnQ1h/+o5Trnumx5i/IOy0cF1Cc9koeHqmwFmKHyV3yRkoBz4IO/a+UzlsSPbDnkymQSQ4ek3xeH7TAkRbrHVTmOf7w1k2GJKkECQ9vOHrho3xzhBC/8iT7DcBDfmPXSqQJbV6FewUO+hGmArYWh9W3kKSdYpIGnZXYwTGDleEDDs8JroGraP8iOe8sNF7fo51r81oddnWMMYaNYLXXcXQPrYQ6XAu/K4I/ARwT3Y3mkGVXtgbpLmuuwLiXTbGo+pRtxuymOAkUwfKKov2j4WV5EhfdmgJ6h6287yI35O5LGm8XRzZaYqDGlSjvQIeAiP9B/oUNgRXTlhfS9Inc/047b02yTHNELa4huVIEvPKrXVOTsEvO0PPYSiU4g2tUS1G5esfJsTEpIa7BuAQq/WpYV9/ 2RuIZ7rY Bp986rt6x6wVjCXlPsywOGBkpwYSOlS2D43XYlJo5rhTaIW4/C60Kt8ygA5tmPPf/ccZsPeLv3DbDsAIQmddOREmteI+oF97GfEswcQ/TEHrnLsxskOf/DOiE/Ml75Z+4gnpXXAF7cX/wVtpClYQyR4VERW5KIF1N8ZJFxBvEXdvCLc7d998ISL8xYtaifXYXcbhfHQbmmDAIQJE7UKr71zEXo9aGyDkHaAWa/PJYhqKs3o3+tmkhwvPZeQ== 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 2/10/24 03:46, Andrew Morton wrote: > On Fri, 9 Feb 2024 12:20:36 +0530 Anshuman Khandual wrote: > >> HugeTLB CMA area array is being created for possible MAX_NUMNODES without >> ensuring corresponding MAX_CMA_AREAS support in CMA. Let's just warn for >> such scenarios indicating need for CONFIG_CMA_AREAS adjustment. >> >> ... >> >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -7750,6 +7750,13 @@ void __init hugetlb_cma_reserve(int order) >> } >> >> reserved = 0; >> + >> + /* >> + * There needs to be enough MAX_CMA_AREAS to accommodate >> + * MAX_NUMNODES heap areas being created here. Otherwise >> + * adjust CONFIG_CMA_AREAS as required. >> + */ >> + VM_WARN_ON(MAX_CMA_AREAS < MAX_NUMNODES); > > Could this simply be fixed up in Kconfig logic? CMA_AREAS should default as (1 << NODES_SHIFT) ? But the system admin might want to create more heap areas for other purposes as well. The idea here is to ensure MAX_CMA_AREAS is at least MAX_NUMNODES if HugeTLB support is enabled. Do we have some other methods ? > > And I think this could be detected at compile-time? BUILD_BUG_ON()? Right, was thinking about this at first. Makes sense, will change here, seems to be the right location for a build check as well. > >> for_each_online_node(nid) { >> int res; >> char name[CMA_MAX_NAME]; >> -- >> 2.25.1 >