From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-199.mta1.migadu.com [95.215.58.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EC45370D57 for ; Tue, 25 Aug 2026 10:16:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787652966; cv=none; b=J3awaIl9BLm15HiaEctS1/iy8yVa3yCsqyogy7TKhfcwtkd0+wBRFUMDKl8k8tJuJ+B+48eQYAIJ637IyoMXKHH9/I1FjK1mhHqdQLjEPUnHFV076+vW5AzGZ43IgiP+jbiBAoKF3NDUypKJgvvEyfZ9QzGgz8GB7Z+4h2GcZNM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787652966; c=relaxed/simple; bh=Tdr/HmJfTxf5L8Y+jdMDmcvzH+SrmMF/W8kD6dxUlKI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=j1BPqhq6shJ0AnbVBOdwiRlZmXgVw0tfcmiXJrXOE7f7WSZh6uAxaNMu5Y861YPmdUYjBAhHnE3o1EitKZbOVDeX9C3qR1k+qMYTcpLfDDxzyvHRGC3tcsvppfrcG04nAHfM2eeP6ymfAlGQLP3TcW8DbTq3HG41ahvGvbt+0uY= 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=jYWCFU5K; arc=none smtp.client-ip=95.215.58.199 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="jYWCFU5K" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=Tdr/HmJfTxf5L8Y+jdMDmcvzH+SrmMF/W8kD6dxUlKI=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787652960; v=1; x=1788257760; b=jYWCFU5KB164URbFDLQBKWigik7j/EdHh6nSnoXU+YhtoV0cVkpA7qd9Ndd+ZnEv7ArAsllV MT/uc6e5Q731d4QzoWn0hpRYV2q2u+6wEsFJ6Oh19lQ4wDNSgaWGlgQt6zpwUeedyIADPZw3dp+ fC3NLl/FoTdQorSjnvp5AY0s= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [100.82.85.74] (101.71.133.200) by smtp.migadu.com with ESMTPS id bcd67e8add5ab7a7; Tue, 25 Aug 2026 10:15:50 +0000 X-Mizu-Trace-ID: bcd67e8add5ab7a7 X-Migadu-Flow: FLOW_OUT Message-ID: <4de2eb8f-5b26-48e3-a331-f2014a922788@linux.dev> Date: Tue, 25 Aug 2026 18:15:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/17] mm/mm_init: skip initializing shared vmemmap tail pages To: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand Cc: Mike Rapoport , Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , David Laight , "Liam R . Howlett" , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song References: <20260825084608.47437-1-songmuchun@bytedance.com> <20260825084608.47437-4-songmuchun@bytedance.com> From: Qi Zheng In-Reply-To: <20260825084608.47437-4-songmuchun@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/25/26 4:45 PM, Muchun Song wrote: > memmap_init_range() initializes every struct page in the target range. > For compound pages with vmemmap optimization, the tail struct pages are > backed by a shared vmemmap page. > > Initializing those tail struct pages would overwrite the shared > vmemmap page contents, requiring users such as HugeTLB to restore the > metadata afterwards. > > Track the compound order for HVO-backed sections and use that metadata > to detect struct pages that fall into the shared tail vmemmap range. > Skip those shared tail pages in memmap_init_range(), then initialize > pageblock migratetypes for the processed range with a helper after the > per-page initialization loop. > > Keep direct mem_section access inside sparse helpers by exposing > pfn_to_section_order() to users that only need the order associated with > a PFN. This lets memmap_init_range() skip shared tail vmemmap pages > without exposing __pfn_to_section() to !SPARSEMEM builds. > > This is a preparatory change for consolidating handling across users of > vmemmap optimization, and it also avoids redundant initialization of > shared tail vmemmap pages during early boot. That early-boot benefit > appears only once HugeTLB is switched to this common handling, since > HugeTLB is the early-boot user that creates those shared tail vmemmap > pages. > > Signed-off-by: Muchun Song Acked-by: Qi Zheng Thanks, Qi