From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B147303CAE for ; Wed, 17 Jun 2026 06:56:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781679376; cv=none; b=ThAwTqV9WPghUvsX13xuWc1c81bMNfmWWv7CG2kvzWVkJaXTApvCNVs0s1AUJ3lhpL4KvIF7jPqM+GT7ZUF7a+kM4cq1B8/czszfy2ZI/ozshWg3NhB0eJH+ivoE2mqd4BI9RAetSuzbWnI5ABvcpcw3XkmbSm19I2qdekdlw3c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781679376; c=relaxed/simple; bh=X7u9U5tzyoBtd5W7JxyT8zSNRe64uGQWzGNrcjiX8NQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=f45R7W8sZ2EoVg3OuwwAEMoW4g3rXqAR2Oy3NBtL+7CdGWF/gDfwBpQ3zzqxtLPXfviqpwn7BdFlMiFoiPbGAJ0RYkAj2ouOHGaDU6EGrO/m1n4f68sBy4KEde9UQrk/RxMwjidtgXUwVOm5P7iRKUohLu+wd/Y1HKxiBzWNbw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ttcAU0uv; arc=none smtp.client-ip=95.215.58.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ttcAU0uv" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781679372; 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=Pd8gbWlNCzyQkqrU5ZHSLBlgsjsUTsM3D0rkfq8QUW0=; b=ttcAU0uv6c4ydMwv2tlS3Wzs4bC6X98JE1iuB1K3Xm0VC+m/C51NpfOzx5cdFQzkyMK+vp YRs/Mhod1qpU9xD9YJL4sDSKUoMdQz4FqoMOwK397a4Fy+3cVA52NT6LDbcvy25HoPukjR 7w3/v5h8h9a09AS9H3WcWW1T1bs3iCw= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH v4 00/19] mm: Refactor bootmem gigantic hugepage allocation X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20260612035903.2468601-1-songmuchun@bytedance.com> Date: Wed, 17 Jun 2026 14:54:39 +0800 Cc: Oscar Salvador , David Hildenbrand , Madhavan Srinivasan , Michael Ellerman , Muchun Song , Mike Rapoport , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nicholas Piggin , Christophe Leroy , Ritesh Harjani , "Aneesh Kumar K . V" , linuxppc-dev@lists.ozlabs.org Content-Transfer-Encoding: quoted-printable Message-Id: <1213AB34-BDA3-4EB0-A2D1-83A4744C710F@linux.dev> References: <20260612035903.2468601-1-songmuchun@bytedance.com> To: Andrew Morton X-Migadu-Flow: FLOW_OUT > On Jun 12, 2026, at 11:58, Muchun Song = wrote: >=20 > This series is split out from the earlier larger series "mm: = Generalize > HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches = of > that series as a standalone set of fixes and preparatory cleanups = around > bootmem HugeTLB handling, sparse initialization ordering, and related > vmemmap setup. >=20 > The first patches fix a few bugs found while reviewing the existing > code, including incorrect bootmem HVO handling, wrong vmemmap > registration arguments, a powerpc compound-vmemmap tracking bug, and > too-late initialization of gigantic bootmem HugeTLB struct pages. >=20 > The rest of the series reorders early memory initialization so the > relevant zone state is available before sparse and HugeTLB boot-time > setup runs, then simplifies the remaining bootmem gigantic hugepage > allocation path and removes code made obsolete by that rework. >=20 > At a high level: > - patches [1-4] fix boot-time and arch-specific bugs > - patches [5-12] reorder and simplify sparse/mm/hugetlb early init > - patches [13-19] refactor bootmem gigantic hugepage allocation and > remove obsolete helpers and state >=20 > Changes since v3: > - patches 2-4: add Cc: stable@vger.kernel.org to the applicable fixes > - patch 3: collect Reviewed-by from Ritesh Harjani > - patch 15: move pfn_to_zone() before hugetlb_vmemmap_init_early() > instead of using a forward declaration > - patches 15-17: collect Acked-by from Mike Rapoport where applicable > - patch 15: collect Acked-by from Usama Arif > - patch 18: clarify that the changelog also covers the early CMA > bootmem allocation fallback refactoring > - patch 19: initialize pgdat at declaration in > __init_deferred_page() and collect Reviewed-by from Mike Rapoport >=20 > [1] = https://lore.kernel.org/linux-mm/20260513130542.35604-1-songmuchun@bytedan= ce.com/ Hi Andrew, Would you mind picking these up for the mm-unstable branch? Almost all patches have received a Reviewed-by or Acked-by. Regarding the Sashiko review comments, it reported 5 issues in total, = and I've verified all of them: - Patches 7 & 11: These are pre-existing issues and not introduced by = this series. - Patch 14: This is a false positive. - Patches 8 & 9: These are valid observations but not a practical issue. = The report mentioned: "moving these reservations after free_area_init() artificially = inflate nr_kernel_pages and nr_all_pages, potentially causing an early = boot OOM" However, this aligns the 1GB HugeTLB allocation behavior with the = existing 2MB HugeTLB allocation, which already behaves this way. So it won't = introduce new risks. Thanks for your time! Best regards, Muchun >=20 > Muchun Song (19): > mm/hugetlb: Fix boot panic with CONFIG_DEBUG_VM and HVO bootmem pages > mm/hugetlb_vmemmap: Fix __hugetlb_vmemmap_optimize_folios() > powerpc/mm: Fix wrong addr_pfn tracking in compound vmemmap = population > mm/hugetlb: Initialize gigantic bootmem hugepage struct pages earlier > mm/mm_init: Simplify deferred_free_pages() migratetype init > mm/sparse: Panic on memmap and usemap allocation failure > mm/sparse: Move subsection_map_init() into sparse_init() > mm/mm_init: Defer sparse_init() until after zone initialization > mm/mm_init: Defer hugetlb reservation until after zone initialization > mm/mm_init: Remove set_pageblock_order() call from sparse_init() > mm/sparse: Move sparse_vmemmap_init_nid_late() into sparse_init_nid() > mm/hugetlb_cma: Validate hugetlb CMA range by zone at reserve time > mm/hugetlb: Refactor early boot gigantic hugepage allocation > mm/hugetlb: Free cross-zone bootmem gigantic pages after allocation > mm/hugetlb_vmemmap: Move bootmem HVO setup to early init > mm/hugetlb: Remove obsolete bootmem cross-zone checks > mm/sparse-vmemmap: Remove sparse_vmemmap_init_nid_late() > mm/hugetlb: Remove unused bootmem cma field > mm/mm_init: Fold __init_page_from_nid() into __init_deferred_page() >=20 > arch/powerpc/mm/book3s64/radix_pgtable.c | 7 +- > arch/powerpc/mm/hugetlbpage.c | 13 +- > include/linux/hugetlb.h | 24 +-- > include/linux/mmzone.h | 7 - > mm/cma.c | 3 +- > mm/hugetlb.c | 259 +++++++++++------------ > mm/hugetlb_cma.c | 44 ++-- > mm/hugetlb_cma.h | 8 +- > mm/hugetlb_vmemmap.c | 120 +++-------- > mm/hugetlb_vmemmap.h | 5 - > mm/internal.h | 14 +- > mm/mm_init.c | 86 +++----- > mm/sparse-vmemmap.c | 26 ++- > mm/sparse.c | 48 +---- > 14 files changed, 251 insertions(+), 413 deletions(-) >=20 >=20 > base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81 > --=20 > 2.54.0