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 C25CFE6C617 for ; Tue, 3 Dec 2024 08:21:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 435586B007B; Tue, 3 Dec 2024 03:21:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E53C6B0083; Tue, 3 Dec 2024 03:21:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FAEE6B0085; Tue, 3 Dec 2024 03:21:23 -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 1287F6B007B for ; Tue, 3 Dec 2024 03:21:23 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B7F10C076B for ; Tue, 3 Dec 2024 08:21:22 +0000 (UTC) X-FDA: 82852953078.02.CF3BEDD Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) by imf19.hostedemail.com (Postfix) with ESMTP id 1F4651A0004 for ; Tue, 3 Dec 2024 08:21:04 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jCc12JLi; spf=pass (imf19.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733214069; a=rsa-sha256; cv=none; b=edWI+/09revfXoabjaw5yKzPzhzqCTileIF1dUiKWbFqaN4BXWQXrs7dGBXsWiJP5YSx6N UlntjkQhXzZA61x9nsyOMWk3CrTK2NYFZnqvbzPSPMZSMaM65P2QgMZxR82stR44I5mLcR 5W2heRRZv4GQM5N7NGVY8u2wkeFNQj0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jCc12JLi; spf=pass (imf19.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733214069; 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:dkim-signature; bh=MyB1FtEs1wS782QrJMZLEc0bIHq1bVJJUh447GB5OD4=; b=E15B23j46604Jen0wiKEA8j8zNSBoHfQkTLSq1TwHWuDYZirxL5Ijceuy3teclawQfIQHE aPiv60zScoLe2x0s34al1XQDecria9krVoJEHFck4iuEhMgL0/x5Ctx2Ce137TdnFelhdO xLUTV2p9lN5Q1hclUbEOc8meIF3S/ek= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1733214076; h=from:from: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=MyB1FtEs1wS782QrJMZLEc0bIHq1bVJJUh447GB5OD4=; b=jCc12JLi+cyX3ScPSdCjHHorUnaPzxF1KYMZQ7lxBAdosoxtkV6LAfSzXKwpY1T6H+p4u+ ra/OLW5BZuWxjg+TFrv2JlpRcU/SQHkOmw/CCALDB3WT3cDbbULK/R+iEtQtoalziuxwBF neV3uQKwRFbswdmhH8e8bfrZPcXe3Bo= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: [PATCH V2] mm/hugetlb: Make __NR_USED_SUBPAGE check conditional X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <3733d1e8-6e9d-4337-aeda-a6d5366d4a4c@arm.com> Date: Tue, 3 Dec 2024 16:20:38 +0800 Cc: linux-mm@kvack.org, Andrew Morton , Oscar Salvador , linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C1A9184-7432-45CB-89E4-D0A62C992C76@linux.dev> References: <20241203023207.123416-1-anshuman.khandual@arm.com> <3733d1e8-6e9d-4337-aeda-a6d5366d4a4c@arm.com> To: Anshuman Khandual X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 1F4651A0004 X-Stat-Signature: 31cnx3owjnji5ddn4uc93z1rgutj85dy X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1733214064-699382 X-HE-Meta: U2FsdGVkX19RHh3Ukr2+gXMbmBKgNLTm8YL5xjH4Rc4jmlzswMgHhineV1rb1cdJRd36xuFztc0Zwvrur8L689jgXrcIARFEYcEXnAbWgE5d/KHMS0HYgsUXg7CgegnedTArvjt6zwYqE7vAirN3xnDfjdzGOVkro0wIoCn6s1xiWc3O7QxpuV4ZLT+zNHjTzUB6BsLtUMDj4sQCFZb1ODS23omWP2fcjjoHNAeRbva5fXJThfM4aAc7I7Ck1H3TtbTvM4JOU8eY6PkD99dbeZ3dmXGuUH6Mna6lxK6TvYmDG14q8ItZ+4mcega2vfGCClZ+rKz/PXWtUUQxjL6PytgoDrsMlYWhDUp/JFiSFWDKox+XzvK6TNFonQGUs7ksduCaphUr5D96KF2t72bYCKgnxXlvLKB4lrbO+qNZ4RXuWpvaPMmxIucKLQJNMm9FDRNhkDZQ3C5Ncuw4HlMI0Hx5XEZ1zkXo51VGy5PkSu7Ng4pmKqTyOSBnWIF69ekxSCkeJ4NhKcUxClKKHsxKHWPXPUThNCDgurnuO6cIICRnQIvyDkHmGXLQACv+/5k2jhsXtBRVySm54QnoLWq9hM7R25Pv+knunCZqxeo2fghkK8ufdVI21vrayljXMrB9JTfKKcmU88p4o+R+INjjzl4mmdQ71NNM4nhD+9UNVoLjDLVHf7knU408QHgxDMMevtaa6XLqsWbM2EK3pDIDGeUDKXMQy5smyLtg1W0jbPdRxEFY6KeXYRaFlX7AvEAHZ+2lYkwFDBfWG7jCNqs7UTi0uSwAHmWa6giKfqADOvhi7vwpdh5e6IQNOSKbH+9ibEPUaAH5A/rGTh67wXeSDZeOnstfem5o89na7N5oUP4w2DRHhokb+xQDiwd3l8Hi/cRK6xXfIdb39YCFYwlkxiITV5O2cSKg5F+87W/PUj5u9owAGL955MRCQD54U9o/rBD5GbZgT/v5eVuyVmb QuKo9wqU 4JhWEcTd5xJfGCc2TIt0JZNR3B2ZeyPQ2kRYAWGQHzEyACa3EKCv6M3DnYbSK6IhFpuWBrCUqfItVDHLN5xjAZ5O43M1f96k+jdfxY2s5ulZi4D+8JFKdIvJgJry4VfVTaz/j2ABV1MIBG2nof2MSg28NZm8NJRQ1J7xDS/JpViZQUjvK14jCJtVgfVO5affRe6ebGhvBZvvXBamZ03mfppUK001eFfO31hauhTQ3uo6aP/91A8s6TkYFVrXvVzPffWHSE7dRd2v4ekRWTqYpmb/gmbDaPxskEAVkJiMIbyhgk3qBEaR7SzwaSetR80ffFde6ldtMC/Wd8zWCQe6KJ0cPq+e9CQcRz6RTsPAEvj1SRnt+R19BcjO5ph3xBm4BFrYTmWq8yatWu+AkVHNyOO2IKvqMd18vQLJXWiLvqXzGlz0= 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 Dec 3, 2024, at 15:46, Anshuman Khandual = wrote: >=20 >=20 > On 12/3/24 08:59, Muchun Song wrote: >>=20 >>=20 >>> On Dec 3, 2024, at 10:32, Anshuman Khandual = wrote: >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> Changes in V2: >>>=20 >>> - Fixed #ifdef with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP per Oscar >>>=20 >>> Changes in V1: >>>=20 >>> = https://lore.kernel.org/all/20241202090728.78935-1-anshuman.khandual@arm.c= om/ >>>=20 >>> mm/hugetlb.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>=20 >>> 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; >>>=20 >>> - if (size_to_hstate(PAGE_SIZE << order)) { >>> + if (size_to_hstate(PAGE_SIZE << order)) >>> return; >>> - } >>> + >>> BUG_ON(hugetlb_max_hstate >=3D HUGE_MAX_HSTATE); >>> +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>> BUG_ON(order < order_base_2(__NR_USED_SUBPAGE)); >>=20 >> Hi Anshuman, >>=20 >> __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. >=20 > 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. Thanks. >=20 >>=20 >> Thanks. >>=20 >>> +#endif >>> h =3D &hstates[hugetlb_max_hstate++]; >>> __mutex_init(&h->resize_lock, "resize mutex", &h->resize_key); >>> h->order =3D order; >>> --=20 >>> 2.30.2 >>>=20 >>=20