From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794224028; b=af02aUQLMcyhNQV73w+NwE5NNwQlUEFVjMB3Ogu0d+JWPNfLfhgmqVPyt5+x+mF8mx0q qy9jCBfb/iMzzX9FhphNprHeu+ZoatZvQ4gqnv5NkhcHIZwkpYDiYsiaIZyepV/6aWSOL EF7xRmq727bdKdmToIbHE5ec9vTbAWYEfg45hxvdJQAW4EDd6nytuy1APaDQvUL5d8b7B 1FpP71T2qVQ5nFEiA1LZG2Nssz8QRO/sPLt+DfeuV4v+x8CSeAKuW1TtqnvEnGDSuHY+q qQk7J1OFKOoBtaf6ZOrEQBhoXDQYwR49AImU2cmOSPVGYQYtLwv1oQgxmz9J7e9fKiQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794224028; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To; bh=gkT4fe5CJwp7XAtvSBn0G3WSLvL/1VCPfATmUEKUqdc=; b=o9CN2hkS6vE4tT5M9qSmJAl6danWYz8EK0wJb+Meat8pEA1n7RYRJ0+QB7252GUHnwTr mX/v9dIbmKRw2veKNR5LcjlnIjKJ2ZkcDnVu/kMixa99cCwEZXaZsSdApZDezhA4GKdka gbUqqFY9FpaLM384PazofQyuOqPueXYy6+142T75t36mflBwhK2dIuZRedn0z5hc9VJH9 hQyjEj7jDrIs6eucnbPScb55d7y2TscAoLZiV58dx2v0ooF3hG69k7Ic/VQGDwjMj5IG+ 6g/WEQAlkbcKKM28D/5LV65Dw4SdEmxcbHLMJ1lxwUJbPsOpJgUJfbKQxSvnNwaEVGQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TRmNFR5N; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E85A4606A333 for ; Mon, 9 Nov 2026 11:33:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TRmNFR5N Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24F0D1F0089F; Mon, 9 Nov 2026 11:33:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794224027; bh=gkT4fe5CJwp7XAtvSBn0G3WSLvL/1VCPfATmUEKUqdc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=TRmNFR5NGdiaeT/EJyT5AIJBFybSfvC+RFqnrxtntPEiIYgXBWWSdY0ZXLbH3u8k2 LM9cUR88CfTS0kd+K+MIADUPeNj8ViurK4Xvt/R0YEXGxmr35td8HjnHvSc9daasPB vfDsmiS6OXLgcp1GMOQmO9CmLfTBry1jFzABLuITSP2N3h7PBqD8u3RyPLCK7+YvyC 0pOBDNKL9jZLrNm1ICAkZBYP+bg+uv6SyGJ1dDfjvtxthMX9sOaRVOsNhCJMWcTuED aMNRMX06EaGfcsXVT0f+LOkJeo1AHoXwfcNSR6KpeG3/S2XKWkvDw8G4wNk6PeJ3Hs ywEmGQB1o6sqg== Date: Mon, 9 Nov 2026 13:33:40 +0200 From: Mike Rapoport To: Li Zhe Cc: Balbir Singh , muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, akpm@linux-foundation.org, apopple@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init Message-ID: References: <20261105120615.16817-1-lizhe.67@bytedance.com> <20261105120615.16817-3-lizhe.67@bytedance.com> <3e5a9f27-ea35-4557-95d1-70ce359e4c92@bytedance.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Nov 09, 2026 at 05:52:19PM +0800, Li Zhe wrote: > On 11/9/26 5:41 PM, Mike Rapoport wrote: > > Hi, > > > > On Mon, Nov 09, 2026 at 05:22:24PM +0800, Li Zhe wrote: > >> On 11/9/26 11:01 AM, Li Zhe wrote: > >>> On 11/6/26 6:23 PM, Balbir Singh wrote: > >>>> On Thu, Nov 05, 2026 at 08:06:15PM +0800, Li Zhe wrote: > >>>>> Boot-time HugeTLB allocation has to initialize tail struct pages itself > >>>>> when HugeTLB vmemmap optimization (HVO) is unavailable or fails.  For > >>>>> gigantic pages, this can cover a large number of tail pages. Most state > >>>>> installed by __init_single_page() and prep_compound_tail() is identical > >>>>> for every tail page in the same huge page; only PFN-dependent fields > >>>>> need refreshing. > >>>>> > >>>>> Initialize the first tail page normally, copy it into a local template, > >>>>> then initialize the remaining tails from that template with > >>>>> memmap_init_page_from_template().  This avoids repeatedly doing the > >>>>> full > >>>>> __init_single_page() and prep_compound_tail() sequence for state > >>>>> that is > >>>>> identical across tail pages in the same huge page. > >>>>> > >>>>> On an arm64 QEMU/KVM guest using 4K pages and 64 boot-time 1G hugepages > >>>>> (HVO unavailable on arm64 in v7.4-rc1), the measured fallback tail > >>>>> initialization time improved by 36.43%, measured with a temporary > >>>>> jiffies-based printk modeled after the existing timing in > >>>>> memmap_init_zone_device(): > >>>>> > >>>>>    base:             318.4 ms > >>>>>    with this patch:  202.4 ms > >>>>> > >>>>> Signed-off-by: Li Zhe > >>>>> --- > >>>>>   mm/hugetlb.c | 23 ++++++++++++++++++----- > >>>>>   1 file changed, 18 insertions(+), 5 deletions(-) > >>>>> > >>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c > >>>>> index da5d04edf7c1..987f16a5ea27 100644 > >>>>> --- a/mm/hugetlb.c > >>>>> +++ b/mm/hugetlb.c > >>>>> @@ -3219,19 +3219,32 @@ static void __init > >>>>> hugetlb_folio_init_tail_vmemmap(struct folio *folio, > >>>>>       enum zone_type zone = folio_zonenum(folio); > >>>>>       int nid = folio_nid(folio); > >>>>>       struct page *page = folio_page(folio, start_page_number); > >>>>> +    struct page template; > >>>>>       unsigned long head_pfn = folio_pfn(folio); > >>>>>       unsigned long pfn, end_pfn = head_pfn + end_page_number; > >>>>>       unsigned int order = huge_page_order(h); > >>>>>   +    if (start_page_number >= end_page_number) > >>>>> +        return; > >>>>> + > >>>> Can this actually happen? > >>> > >>> No, current callers always pass a non-empty range. I kept this to > >>> preserve the old for-loop no-op semantics for an empty range, but it is > >>> not needed here. I will remove it in v2. > >> > >> I need to correct this. A local Sashiko run pointed out that the bootmem > >> fallback caller can pass an empty range on SuperH. > >> > >> SuperH supports a 64M HugeTLB page size, and with 64K base pages > >> pages_per_huge_page(h) is 1024. HUGETLB_VMEMMAP_RESERVE_PAGES is > >> PAGE_SIZE / sizeof(struct page), which can also be 1024 or larger on a > >> 32-bit SuperH configuration. > > If the only difference is unnecessary initialization of the template on SuperH, > > we don't care and you can drop that if. > > It is not only initializing the local template. The code first > initializes one page with __init_single_page(), prep_compound_tail(), > and set_page_count(), and then copies that page into the template. > > So if start_page_number == end_page_number == pages_per_huge_page(h), > the old loop is a no-op, but without the check the new code would update > folio_page(folio, start_page_number), which is outside the HugeTLB > folio. A recent patch to arch/sh indicated that hugetlb is never used on sh: https://lore.kernel.org/linux-mm/auJI2blzfpFD9yLe@kernel.org/ And it seems none of upstream sh defconfigs can hit it. > Thanks, > Zhe > > > > >> In that case the old for loop is a no-op. So I will keep the empty-range > >> check in v2, before creating the seed template. > >> > >> Thanks, > >> Zhe > -- Sincerely yours, Mike.