From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-68.mta1.migadu.com [95.215.58.68]) (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 929B13DD846 for ; Tue, 25 Aug 2026 10:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787654424; cv=none; b=l3mOGj8LSRTmb5byWt0XO6FstFZSUTccN9x50xs2RdFD9no9X692NoR+iWq5riC5RwPEeXtIh4GYX3nR7AcxljkY49vc53IcOOP/kjZboT8v33KDYTonZOC7oqnWf874DqzjClKZ1xQ4WmvnJmaa8Yp1lMTFkNJSLWO8kJCj5fM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787654424; c=relaxed/simple; bh=4HCdqaL2UsJl3vhnbCh80t3WyCZKmIVtpPQk8zrG2d0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FTKm7bJ4LbZ1KSDTwvYk7KkEtd91k8ThCHGN2gz6a23avFq6bGU+crPe0OXSORnxIoTXu8xjsL9IrYD5EUS1dWprVVuZp2AYJMztIqU2zM/v+uO4WWOEb+sfp78qBrjS+Oruggg7O64XNKJujqHdJ6GQkPLVXDs39IjLbv21oTM= 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=dBOcOR09; arc=none smtp.client-ip=95.215.58.68 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="dBOcOR09" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=4HCdqaL2UsJl3vhnbCh80t3WyCZKmIVtpPQk8zrG2d0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787654419; v=1; x=1788259219; b=dBOcOR09+4/zZYWeFG/SjOn26eOzwP1JmzqHOiZBrVeAPoRm8ZuGTwBIZylKr5wUCGOwl+va mP3/eNbWWiQBoI0rek60AbnfG6mK54vw6x68EtHm9btgj7JuMmK0MhRPaKjn/h8Y9d+i3AQ8SDL NnhRLedgLxa9kaFZJLjtjROc= 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 22f5c38e0082be38; Tue, 25 Aug 2026 10:40:19 +0000 X-Mizu-Trace-ID: 22f5c38e0082be38 X-Migadu-Flow: FLOW_OUT Message-ID: <5d60e20a-64cd-4ce5-bc8b-86f0c976e618@linux.dev> Date: Tue, 25 Aug 2026 18:40:09 +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 04/17] mm/sparse-vmemmap: initialize shared tail vmemmap pages on allocation 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-5-songmuchun@bytedance.com> From: Qi Zheng In-Reply-To: <20260825084608.47437-5-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: > The shared tail vmemmap page allocated in vmemmap_get_tail() used to be > left uninitialized, because memmap_init_range() would later overwrite > it. That forced users such as HugeTLB to defer the initialization to > their own setup paths. > > Now that memmap_init_range() skips shared tail vmemmap pages, initialize > them immediately in vmemmap_get_tail() with init_compound_tail() > instead. > > This moves the initialization to the point where the shared tail page is > allocated and avoids relying on deferred handling in individual users. > The remaining deferred initialization in HugeTLB will be removed once it > switches to the section-based vmemmap optimization mechanism. > > Signed-off-by: Muchun Song > --- > mm/sparse-vmemmap.c | 12 ++---------- > 1 file changed, 2 insertions(+), 10 deletions(-) > > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c > index aa6a4a2fae98..107215cf8488 100644 > --- a/mm/sparse-vmemmap.c > +++ b/mm/sparse-vmemmap.c > @@ -338,19 +338,11 @@ static __meminit struct page *vmemmap_get_tail(unsigned int order, struct zone * > tail = zone->vmemmap_tails[idx]; > if (tail) > return tail; > - > - /* > - * Only allocate the page, but do not initialize it. > - * > - * Any initialization done here will be overwritten by memmap_init(). > - * > - * hugetlb_bootmem_struct_page_init() will take care of initialization > - * after memmap_init(). > - */ > - > p = vmemmap_alloc_block_zero(PAGE_SIZE, node); > if (!p) > return NULL; > + for (int i = 0; i < PAGE_SIZE / sizeof(struct page); i++) > + init_compound_tail(p + i, NULL, order, zone); Until section->order is set, vmemmap_optimizable_pfn() (introduced by patch #3) will always return false. As a result, the initialization here won't actually take effect until patch #10. Acked-by: Qi Zheng Thanks, Qi > > tail = virt_to_page(p); > zone->vmemmap_tails[idx] = tail;