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 5B118E7716C for ; Wed, 4 Dec 2024 02:46:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9D086B007B; Tue, 3 Dec 2024 21:46:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4C8F6B0082; Tue, 3 Dec 2024 21:46:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D149B6B0083; Tue, 3 Dec 2024 21:46:44 -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 B1A496B007B for ; Tue, 3 Dec 2024 21:46:44 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 67A641A0D60 for ; Wed, 4 Dec 2024 02:46:44 +0000 (UTC) X-FDA: 82855738182.25.6F58AAC Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf01.hostedemail.com (Postfix) with ESMTP id 6C5A54000A for ; Wed, 4 Dec 2024 02:46:31 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf01.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=1733280396; 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=akduL1ba1MaOhMRU7xplVPcZ1ie/u/p+lQ7+6CvqMrU=; b=YdO4UVuT5wlk75kH/d0u4YeMvRNGfaJF38lNwU1ckxS/TF0HJ7+DThMfFLvl9TEFboQBKU WK/W3lNLmScan6egix/amYYUUOAP0PswR3Pd2itd27wWbdHkdX/c8NF7zXqFnlB9kM0YjV 61uABG+l9LWLzlwounTBoAuEIW1CJyA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733280396; a=rsa-sha256; cv=none; b=xTg7vW9hexQim50DnlHtPFMFU1sOlR/SHxIdatAZ8OccVsK3upG1anDPwaaFfqrYAGo2Hg kmvY3LX+Uojn9r4XplwkoywRPTJOeiPaatsqsK4Yg3quosuXMtiU9qsQrYO2YJyBL/HwpF l9n2c/CXw5uDeIDP5jzIjAWE8keS3Lc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf01.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com 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 F2D41FEC; Tue, 3 Dec 2024 18:47:08 -0800 (PST) Received: from [10.162.16.41] (a077893.blr.arm.com [10.162.16.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 720823F5A1; Tue, 3 Dec 2024 18:46:39 -0800 (PST) Message-ID: Date: Wed, 4 Dec 2024 08:16:36 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] mm/hugetlb: Make __NR_USED_SUBPAGE check conditional To: Muchun Song Cc: linux-mm@kvack.org, Andrew Morton , Oscar Salvador , linux-kernel@vger.kernel.org References: <20241203023207.123416-1-anshuman.khandual@arm.com> <3733d1e8-6e9d-4337-aeda-a6d5366d4a4c@arm.com> <9C1A9184-7432-45CB-89E4-D0A62C992C76@linux.dev> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <9C1A9184-7432-45CB-89E4-D0A62C992C76@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: a8j6gr9i1bho9cuop7jbqxtcaa1u1a56 X-Rspamd-Queue-Id: 6C5A54000A X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733280391-583846 X-HE-Meta: U2FsdGVkX19TscJDDEARdD5iBcI7wB6X159HwxKeWD3LJlZaEu7tq2QGolG8jdZ8FoMb3JfDL1dWFXUqHnn/iF1NAH9vcWy3CYOi8Tpwww0C5qVFZT1u7/9CNHGLnIoOFmCYXWTLTpVGrljdfwuefixDUWjFrGS3dvXylfUUPn0pbZsJ2DoP60IEGyiRj1kkF+4w6zvCUTuIaiIpCBm9LL7Xjs7MVFyvEgOf8QgMgtMiaJouA4zSN9Ywa7OvfEX3kIfLZDVxhP3tAnNWy7kQys5z6z2+qV/dztu0aE5Dkv/KzeGZSJIkbJTkWcZjnAUs5Lwh4deiY9/6WN8Y34q8630vn/LboywfxZONmJYV7HUdMBR0P2iZiG8A4VDJlfFBXWqfmYt0y2u8d6lKx7GDMyb1OIOvz1AsC8pHKKQWoDgvvPwOks8ApfJ7xgoeeYNLST5+9Mq6LMSrTCE3x9djlIu4TELRLxpiblME751plgvpNQruoQwFPn+BtDgD2rbzuJqwBCcUn4qPPaIMrbZH48bw6A/oVrp1LEjTHYGupNBDulYokYAgkAAwbU9/tqHi4mK12+55I/TpSnZBnrIvzjcr5xYG/U7EGEgysGsW7up+TV2PWMdXfp9YDwfEcjueJvPAPww85el4pWxJobsXSDbhZpiW3vRHYlH/8OfGTPCCFPWjwSn0yDmAzMJsJ8b7kyMOyv0yJjMpu4ZlYyVNAVMShjbDJyKRXf/rk2XugylyiLSHp3hdsIo9UKGe0x2Wh+UxWUJEJH4/wJDArtOL9Xoz997SLvUDLecmU31F06189k4xWN8or4iXe4eQHSPSMPxXBfaGAG6ZOoCVpcD6RF5ERKsKHJFv+H01729InmRFnWmmwC4zcDHN4K9EXGUAqhRaJCSJE424iY9eCrr8SgoH2+IIzmTWOMk49yw2uN1CI40QjYMl0h5a0yD1CnseQfzrvcdx7Jo7psu5bEB DADQ4Srx L/nKKNdcHVxO4rJRG4XSPZ/NsSc3bg8K7L9ClY8L/F1Y0NdOF70+yHUXSKsG1sTlv6uxViOzQvU1lRq3417XY6ajxKGjIvTgOKUIi6tzmJr5Y1uPV79j6asF9mhl8TD9Qet4oNY9i0FSN4xyodK4hTCFtcPQKA8qhbsq12PTqDI0mz0n8zKwpZVgZ2I0lf9oLK741AHkckeaYlNRaVfWWKykakLQtKszi561yXEKE85aW/k4OFNP/sYK+cT04FQaktJBwqOPktlJhCtW3nVbmMArwKlUFNT1tyKrgQd8t5nXyR5SJOCkDv49S5+6hTdfrj250e1PQEWtDdGUS8KdqU5cbHvSeVQEQN5yEjZ61AuARcfxNg2AzpiT9UDPXIaGwWe8aXLM9o+woIGE= 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 12/3/24 13:50, Muchun Song wrote: > > >> On Dec 3, 2024, at 15:46, Anshuman Khandual wrote: >> >> >> On 12/3/24 08:59, Muchun Song wrote: >>> >>> >>>> On Dec 3, 2024, at 10:32, Anshuman Khandual wrote: >>>> >>>> The HugeTLB order check against __NR_USED_SUBPAGE is required only when >>>> HUGETLB_PAGE_OPTIMIZE_VMEMMAP is enabled. Hence BUG_ON() trigger should >>>> happen only when applicable. >>>> >>>> Cc: Muchun Song >>>> Cc: Andrew Morton >>>> Cc: Oscar Salvador >>>> Cc: linux-mm@kvack.org >>>> Cc: linux-kernel@vger.kernel.org >>>> Signed-off-by: Anshuman Khandual >>>> --- >>>> This patch applies on v6.13-rc1 >>>> >>>> Changes in V2: >>>> >>>> - Fixed #ifdef with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP per Oscar >>>> >>>> Changes in V1: >>>> >>>> https://lore.kernel.org/all/20241202090728.78935-1-anshuman.khandual@arm.com/ >>>> >>>> mm/hugetlb.c | 6 ++++-- >>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >>>> index ea2ed8e301ef..e6a5b21e3578 100644 >>>> --- a/mm/hugetlb.c >>>> +++ b/mm/hugetlb.c >>>> @@ -4513,11 +4513,13 @@ void __init hugetlb_add_hstate(unsigned int order) >>>> struct hstate *h; >>>> unsigned long i; >>>> >>>> - if (size_to_hstate(PAGE_SIZE << order)) { >>>> + if (size_to_hstate(PAGE_SIZE << order)) >>>> return; >>>> - } >>>> + >>>> BUG_ON(hugetlb_max_hstate >= HUGE_MAX_HSTATE); >>>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>>> BUG_ON(order < order_base_2(__NR_USED_SUBPAGE)); >>> >>> Hi Anshuman, >>> >>> __NR_USED_SUBPAGE indicates how many struct pages are used to store >>> extra metadata for a HugeTLB page. So we need to make sure the order >>> of a HugeTLB page should be bigger than or equal to order_base_2(__NR_USED_SUBPAGE). >>> So It is not related to HVO. I don't think the changes make sense. >> >> I did think about that but order_base_2(__NR_USED_SUBPAGE) actually >> turns out to be just 2 as __NR_USED_SUBPAGE is 3. Would not HugeTLB >> size be always greater than four base pages in reality, thus making >> this BUG_ON() check just redundant ? > > Currently, there is no architectures supporting hugetlb page smaller > than 4 base pages. I think the smallest size is 64KB in arm64, but who > knows whether if certain architectures supports 8KB in the future or > we want to uses more struct pages to store metadata for increasing > __NR_USED_SUBPAGE (e.g. change it to 17). So I tend to keep this > BUG_ON remain to catch unexpected bugs. Sure, fair enough.