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 388B9C76196 for ; Tue, 11 Apr 2023 08:08:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A6866B0106; Tue, 11 Apr 2023 04:08:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 654ED28005C; Tue, 11 Apr 2023 04:08:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F3C328005B; Tue, 11 Apr 2023 04:08:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3EDCF6B0106 for ; Tue, 11 Apr 2023 04:08:10 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 07EB6A0761 for ; Tue, 11 Apr 2023 08:08:10 +0000 (UTC) X-FDA: 80668382340.29.EDD991F Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf23.hostedemail.com (Postfix) with ESMTP id AA079140012 for ; Tue, 11 Apr 2023 08:08:05 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=AbNqF5VE; spf=pass (imf23.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681200486; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D4QSWpLiRyPCEsA0lEwex1yX5fUIzx7Cp5Q3nr3znk4=; b=3Eg8qCT+MDqFenaeM9mamhsjLz6SfJl67OkaJG7rksBS2Wo0iMwC9waeEp3zrn9JgrVxk4 r95KiXEFxCfwAt4SevuXe7xOSW54B/eT7znMq1Waiiye2l6i5UD64qMY3KbYThtYMLA5za uE3AYYaC8Y53fTEn4fuKbcBIRwqPF2M= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=AbNqF5VE; spf=pass (imf23.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681200486; a=rsa-sha256; cv=none; b=VgkjokFstf6MO76a8YUPyAUqnDsivew7xgUFjA//eiZ+2854lwSKKf7kBZoXLTLeuHoDMl mtnGRiozwXLNh80shlhlS7ycgC+ktb1K8Tbu/U0D4l81dHwtpuPJ+VGEfP5sYBGcjw8SJJ kBU+WUvuu8ssD6NuvUX2xh2OwbSRn1Y= Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33B5mTIo019129; Tue, 11 Apr 2023 08:07:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=pp1; bh=D4QSWpLiRyPCEsA0lEwex1yX5fUIzx7Cp5Q3nr3znk4=; b=AbNqF5VEG+fom1ePLw8K4idzuEG+OYvpIjDIMAHRX5L7905idattzxkMvEk4XYgV7MFE EYuOC4KRFi4RH6NbU5mSHllZyqJsfx2QOB9DZNGOPEelKiw52oqzW3+8IOxb1uJvPgfw s0U4MmlHgRYFNNPP11tLIsaluXZ4aV/sf9wjABQgbO4nZfeUes+dtJfwc8J+H2aLJQgQ TDyAJMc8Xmn2dkdBDYDKJJmf30u3oevZcSkKeQTLlEthD7XZl9dKZRlohfyx4j3g+93Q Nu3uZSACzzgf1V85UWAAcCs7S+LSqBPxGsdIkdByUXEE32XGzoxAxlHRpErdtd10nJ0F +Q== Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3puj2utqh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Apr 2023 08:07:49 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 33B81tmu002004; Tue, 11 Apr 2023 08:07:48 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([9.208.129.117]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3pu0ktk4xq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Apr 2023 08:07:48 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33B87k1B13632148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Apr 2023 08:07:46 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 927D158068; Tue, 11 Apr 2023 08:07:46 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 138A85806B; Tue, 11 Apr 2023 08:07:44 +0000 (GMT) Received: from skywalker.linux.ibm.com (unknown [9.109.205.160]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Tue, 11 Apr 2023 08:07:43 +0000 (GMT) X-Mailer: emacs 29.0.60 (via feedmail 11-beta-1 I) From: "Aneesh Kumar K.V" To: Joao Martins Cc: Muchun Song , Dan Williams , Tarun Sahu , linux-mm@kvack.org, akpm@linux-foundation.org Subject: Re: [PATCH] mm/vmemmap/devdax: Fix kernel crash when probing devdax devices In-Reply-To: <5c30292b-7e68-8897-9ca0-cc800b866ba7@oracle.com> References: <20230407122353.12018-1-aneesh.kumar@linux.ibm.com> <5c30292b-7e68-8897-9ca0-cc800b866ba7@oracle.com> Date: Tue, 11 Apr 2023 13:37:41 +0530 Message-ID: <871qkqdepe.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-GUID: RrClJ-k7h9hP6FZxcs1VpeODXcdF2OPJ X-Proofpoint-ORIG-GUID: RrClJ-k7h9hP6FZxcs1VpeODXcdF2OPJ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-11_04,2023-04-06_03,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304110075 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: s1rujzp5bt5xe6stiz4uk1u5eh6g8zwo X-Rspamd-Queue-Id: AA079140012 X-HE-Tag: 1681200485-132138 X-HE-Meta: U2FsdGVkX18AWiLcKlqNe1w37OqLLwPt4HJFUoJw29Aji7hF+GD3BJloNP1o8jqqNV+b+FT/5pYHb6v95vIveYvWNNWMnb+tHRS6OV84wTWfbAvQpo32g8Gyso298P+iaE/QnHXySsXZ39PNMcaVlMN8eKVIjC5a5gKSLail6Vtah4y4PLMRzwnLVmcifhyZQ+VJNMqvutJHTMWh6pdpX6KXqhyoyno2qpIki2gEFABedz777hfRuTbZO9BltmHu15lJOGWUhFKlU+9fJDsAiwxe7ElYgJyfqnfm9Futh7biBqdET+SRjYDnbNe4QPFHu/FnqKq157Ez9cXXhClj6osz/QZTlv81E7K4Ll/iSCYbrAx/Afto8THzXscPc44yWbi+qRNs9uEqogaSOoof5yszKWr1AeAI83n3Vcu4MtyV5cyUNpevP7v61FbwRWW6I/3aAMFes1TiK1UwZ88ZhfduLG1RXqoZcfT7lfkrXXOdpJb7LVVnwe3H912gnU/GPaqUzGyXZ4+GtVFxLx3a5721iWWOUCkYnuNv/lCLODVu6rPLYWvnv2GTjGuvRa1SF2fMlBF1sTY4f7iuE4YXFmKV0aCEM4ZXstvsbwr/k9oVaDIyHalz7YAiWLo5mXBuEXgXsspZvKDjE8WNsVpA6pVBOdkB/pCoM9j5LJhR7Z/abj8c7x3N+ng+YMqYhjGVl3Jf/I4juZnBNRA/M+i57xDObJZax4JDj0dsdRtGsG/52Cm/MadHkb25CtQQEanLtqMtZV0DEINz98VzErlAwmNlntcxTAuWQ2uOEQpPBP+kmh9mio58THJQ6u01QeAmDrd3EMQi1F6soIBtBLVinT4jqXSrvBRtB7a6L6Hoo93lmulG5soolZdXtP4S64XEQJjtZsOXitJmVMKhIVLASkVCbUCvGNFZy2wf7k2HctSkgPvjC/7yEckXM4hEvKP3tEhEXb+82qoNyIjJ6H3 l5RnvkNa G2rDts6SAAae4MtpwQAPgD2DKUtdRj3Uc6bBhT0+Eh/XnfuIs61egy5Ie68fDEZyG4ckQpzYBpliplUueOhBPLgatmRoLsr6e/rUHvL52ivh7qdbNl2C/slbGEOwh/UEd3WNpxe1jUpMnr1fcm/IgAq5lvIW5nTu4yVJ1vOEAAUZirtmsWavm/7pi9GRDb65YM8VKWtuiH65/txmo5m7TXzTZrpYVdOcrk7s+GbCpFmG2g1ugkPhiSxDS1C1B2lOhWkQi 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: Joao Martins writes: > On 07/04/2023 13:23, Aneesh Kumar K.V wrote: >> commit c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") >> added support for using optimized vmmemap for devdax devices. > > Not really. It added *compound pages* for devdax ZONE device which is what the > commit describes. It is meant to represent the non base page metadata. Should > fsdax support the equivalent, we can have GUP performance on the dax path and > remove today's special zone device case of ref-per-base-page GUP-fast path. > > One was tied when it was brought in but in theory[*] we didn't require anything > from arch-es to do this (contrary to vmemmap_populate()). The commit you should > refer to is this instead: ok the compound page dependency came via commit 6fd3620b3428 ("mm/page_alloc: reuse tail struct pages for compound devmaps") I have now reworked it such that we do static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, unsigned long nr_pages) { #ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP /* * this depends on how vmemmap is populated by * vmemmap_populate_compound_pages() */ return is_power_of_2(sizeof(struct page)) && !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; #else return nr_pages; #endif } > > 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") > > [*] or so I thought before next paragraph > >> But how vmemmap >> mappings are created are architecture specific. For example, powerpc with hash >> translation doesn't have vmemmap mappings in init_mm page table instead they are >> bolted table entries in the hardware page table >> > > Very interesting, I didn't know this (no init_mm) was an option. And my > apologies for regressing s390 :/ So, s390 does not support > vmemmap_populate_basepages() then and always need to go to arch > vmemmap_populate() to create the vmemmap entries. > >> vmemmap_populate_compound_pages() used by vmemmap optimization code is not aware >> of these architecture-specific mapping. Hence allow architecture to opt for this >> feature. I selected architectures supporting HUGETLB_PAGE_OPTIMIZE_VMEMMAP >> option as also supporting this feature. I added vmemmap_can_optimize() even >> though page_vmemmap_nr(pgmap) > 1 check should filter architecture not >> supporting this. > IMHO that brings clarity to the code where we are populating >> vmemmap. >> > I am not sure the last two sentences are right. I would remove, see above and > below comments at the end on why. That is true because i had vmemmap_shift = 0 if arch didn't support vmemmap optimization. Based on your reply above, I have now moved that out and kept vmemmap_can_optimize() modified mm/page_alloc.c @@ -6846,8 +6846,16 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, static inline unsigned long compound_nr_pages(struct vmem_altmap *altmap, unsigned long nr_pages) { +#ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP + /* + * this depends on how vmemmap is populated by + * vmemmap_populate_compound_pages() + */ return is_power_of_2(sizeof(struct page)) && !altmap ? 2 * (PAGE_SIZE / sizeof(struct page)) : nr_pages; +#else + return nr_pages; +#endif } static void __ref memmap_init_compound(struct page *head, modified mm/sparse-vmemmap.c @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) return NULL; - if (is_power_of_2(sizeof(struct page)) && - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) + if (vmemmap_can_optimize(altmap, pgmap)) r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else r = vmemmap_populate(start, end, nid, altmap); .... > >> Fixes: c4386bd8ee3a ("mm/memremap: add ZONE_DEVICE support for compound pages") > > It should be: > > Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound > devmaps") updated. > > But if what you included in your patch was what lead to the crash, then your > problem is not the vmemmap optimization ... as the latter came after. If it's > the hash I included above, it would reduce the affected trees to v5.19+ > >> Cc: Joao Martins >> Cc: Muchun Song >> Cc: Dan Williams >> Reported-by: Tarun Sahu >> Signed-off-by: Aneesh Kumar K.V >> --- >> arch/arm64/Kconfig | 1 + >> arch/loongarch/Kconfig | 1 + >> arch/s390/Kconfig | 1 + >> arch/x86/Kconfig | 1 + >> drivers/dax/device.c | 3 ++- >> include/linux/mm.h | 16 ++++++++++++++++ >> mm/Kconfig | 3 +++ >> mm/sparse-vmemmap.c | 3 +-- >> 8 files changed, 26 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 27b2592698b0..d3f5945f0aff 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -103,6 +103,7 @@ config ARM64 >> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >> select ARCH_WANT_LD_ORPHAN_WARN >> select ARCH_WANTS_NO_INSTR >> + select ARCH_WANT_OPTIMIZE_VMEMMAP >> select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES >> select ARCH_HAS_UBSAN_SANITIZE_ALL >> select ARM_AMBA >> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig >> index 9cc8b84f7eb0..ce5802066d0e 100644 >> --- a/arch/loongarch/Kconfig >> +++ b/arch/loongarch/Kconfig >> @@ -56,6 +56,7 @@ config LOONGARCH >> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >> select ARCH_WANT_LD_ORPHAN_WARN >> select ARCH_WANTS_NO_INSTR >> + select ARCH_WANT_OPTIMIZE_VMEMMAP >> select BUILDTIME_TABLE_SORT >> select COMMON_CLK >> select CPU_PM >> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig >> index 933771b0b07a..abffccd937b2 100644 >> --- a/arch/s390/Kconfig >> +++ b/arch/s390/Kconfig >> @@ -127,6 +127,7 @@ config S390 >> select ARCH_WANT_DEFAULT_BPF_JIT >> select ARCH_WANT_IPC_PARSE_VERSION >> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >> + select ARCH_WANT_OPTIMIZE_VMEMMAP >> select BUILDTIME_TABLE_SORT >> select CLONE_BACKWARDS2 >> select DMA_OPS if PCI >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >> index a825bf031f49..e8d66d834b4f 100644 >> --- a/arch/x86/Kconfig >> +++ b/arch/x86/Kconfig >> @@ -127,6 +127,7 @@ config X86 >> select ARCH_WANT_HUGE_PMD_SHARE >> select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP if X86_64 >> select ARCH_WANT_LD_ORPHAN_WARN >> + select ARCH_WANT_OPTIMIZE_VMEMMAP if X86_64 >> select ARCH_WANTS_THP_SWAP if X86_64 >> select ARCH_HAS_PARANOID_L1D_FLUSH >> select BUILDTIME_TABLE_SORT > > I would remove these and instead use the > ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP, and have your other snip be a second > patch to drop the 'HUGETLB_' part > >> diff --git a/drivers/dax/device.c b/drivers/dax/device.c >> index 5494d745ced5..05be8e79d64b 100644 >> --- a/drivers/dax/device.c >> +++ b/drivers/dax/device.c >> @@ -448,7 +448,8 @@ int dev_dax_probe(struct dev_dax *dev_dax) >> } >> >> pgmap->type = MEMORY_DEVICE_GENERIC; >> - if (dev_dax->align > PAGE_SIZE) >> + if (dev_dax->align > PAGE_SIZE && >> + IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP)) >> pgmap->vmemmap_shift = >> order_base_2(dev_dax->align >> PAGE_SHIFT); > > vmemmap_shift relates to the compound page size we will use in > memmap_init_zone_device(). Otherwise we are back to the base struct page on > PMD/PUD case. Instead move the: > > IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP) > > further below to __populate_section_memmap() ... > >> addr = devm_memremap_pages(dev, pgmap); >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index 716d30d93616..fb71e21df23d 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -3442,6 +3442,22 @@ void vmemmap_populate_print_last(void); >> void vmemmap_free(unsigned long start, unsigned long end, >> struct vmem_altmap *altmap); >> #endif >> + >> +#ifdef CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP >> +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, >> + struct dev_pagemap *pgmap) >> +{ >> + return is_power_of_2(sizeof(struct page)) && >> + pgmap && (pgmap_vmemmap_nr(pgmap) > 1) && !altmap; >> +} >> +#else >> +static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap, >> + struct dev_pagemap *pgmap) >> +{ >> + return false; >> +} >> +#endif >> + >> void register_page_bootmem_memmap(unsigned long section_nr, struct page *map, >> unsigned long nr_pages); >> >> diff --git a/mm/Kconfig b/mm/Kconfig >> index ff7b209dec05..99f87c1be1e8 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -461,6 +461,9 @@ config SPARSEMEM_VMEMMAP >> pfn_to_page and page_to_pfn operations. This is the most >> efficient option when sufficient kernel resources are available. >> >> +config ARCH_WANT_OPTIMIZE_VMEMMAP >> + bool >> + >> config HAVE_MEMBLOCK_PHYS_MAP >> bool >> > As you mentioned in your other followup email it probably makes sense that you > just use ARCH_HUGETLB_WANT_OPTIMIZE_VMEMMAP if we switch this to per-arch. And > then have that kconfig name be renamed into the above. It simplifies the fix in > case it pickups stable trees (the dax vmemmap deduplication came after hugetlb). > The case for the head page reusal case for hugetlb is anyways captured by a > hugetlb static key. will do > > >> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c >> index c5398a5960d0..10d73a0dfcec 100644 >> --- a/mm/sparse-vmemmap.c >> +++ b/mm/sparse-vmemmap.c >> @@ -458,8 +458,7 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, >> !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) >> return NULL; >> >> - if (is_power_of_2(sizeof(struct page)) && >> - pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) >> + if (vmemmap_can_optimize(altmap, pgmap)) >> r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); >> else >> r = vmemmap_populate(start, end, nid, altmap); > > Same comment(s) as further above. I think it should be: > > if (IS_ENABLED(CONFIG_ARCH_WANT_OPTIMIZE_VMEMMAP)) > r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); > else > r = vmemmap_populate(start, end, nid, altmap); Even if arch want vmemmap optimization the ability to use compound vmemmap_populate is further restricted by if (is_power_of_2(sizeof(struct page)) && pgmap && pgmap_vmemmap_nr(pgmap) > 1 && !altmap) Hence we still want if (vmemmap_can_optimize(..)) right? > > In principle all these arches below can support > vmemmap_populate_compound_pages() but now it would require them enable it > explicitly, which I guess makes sense considering this bug you are fixing. But > the arch-requirement is not really if we support optimized-vmemmap or not but if > we support the init-mm at all. OTOH tieing both hugetlb and dax additionally > eliminates confusion around an optimization shared by both, even if the dax > could encompass more. I am not sure what is the arch requirement for hugetlb > vmemmap opt these days. > > arch/arm64/mm/mmu.c: return vmemmap_populate_basepages(start, end, > node, altmap); > arch/ia64/mm/discontig.c: return vmemmap_populate_basepages(start, end, > node, NULL); > arch/loongarch/mm/init.c: return vmemmap_populate_basepages(start, end, > node, NULL); > arch/riscv/mm/init.c: return vmemmap_populate_basepages(start, end, node, NULL); > arch/x86/mm/init_64.c: err = vmemmap_populate_basepages(start, end, > node, NULL); > arch/x86/mm/init_64.c: err = vmemmap_populate_basepages(start, end, > node, NULL);