From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 78AD3B67E for ; Fri, 31 Jul 2026 02:14:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785464053; cv=none; b=l/IdYfpkPvrcK4jD/w8yecQ260JLZ8kHTrKdVEv3eCph35c3EvbVkHQoqUQNBLihFgJxeYBX/jmQoaSj4msDFnrT+zN3KRbWxzcnEVDsjTqgaMN6u78IETMAJo/93B4boFT8+QAppEQsicmf5gbfyygJuRXDCSsjUAdu+WQOE8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785464053; c=relaxed/simple; bh=NkGnDeEOud8e80OMN3pU9tm7Uto2jz2fsc+uQi49WWo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=olifNor4N2LEl5kwAWDsHZf6LBJFL3gTZsD4miE1y3SDhPQEbS8xpfQFoChh37T8VCbt/Qua3lf/xgx7OBoB8EYuXEwxif66x2PtMo++yU8nblpvxAOPXpIwFrx4AHuM/+jRs75Pj0SeKHm/jAKNf3wG3GTWoZLcmSYMbEX8OPk= 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=pAN6jO/4; arc=none smtp.client-ip=91.218.175.172 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="pAN6jO/4" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785464049; 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=1fEupGYGhLWFgoSe/r+XuCrNsAvYCd8RtQFa5T3203Q=; b=pAN6jO/4ybpymCX8FToWqPhTuorFnbVQrXI2DTFHP1wDzq7nQdvF1sji83Co4zdLBIG2TI lDj7vmuTVVX6ivbn/q7D2iufVlZDKIDeOXg9CC9DMSpNqgAiIUdlo9WGTevIk8wuug0MiY 2lV3ww5f8Z/73Do3h/oyBDosIgesvbQ= 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 v2 03/17] mm/mm_init: skip initializing shared vmemmap tail pages X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Fri, 31 Jul 2026 10:13:43 +0800 Cc: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand , Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , David Laight , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <89878C33-9BCD-4FD7-92A0-884CF682CBF3@linux.dev> References: <20260720093127.540540-1-songmuchun@bytedance.com> <20260720093127.540540-4-songmuchun@bytedance.com> <5005C7D3-B3ED-4C62-B611-8465D2BC69FD@linux.dev> <178540851830.2154539.6359871825839331816.b4-reply@b4> <3FCC8989-95DB-450F-95C3-183787DF4D08@linux.dev> To: Mike Rapoport X-Migadu-Flow: FLOW_OUT > On Jul 30, 2026, at 22:32, Mike Rapoport wrote: >=20 > On Thu, Jul 30, 2026 at 09:09:00PM +0800, Muchun Song wrote: >>> On 2026-07-26 12:30:17+08:00, Muchun Song wrote: >>>>>=20 >>>>> #else >>>>> +struct mem_section; >>>>> + >>>>> #define sparse_vmemmap_init_nid_early(_nid) do {} while (0) >>>>> #define pfn_in_present_section pfn_valid >>>>> +static inline struct mem_section *__pfn_to_section(unsigned long = pfn) >>>>> +{ >>>>> + return NULL; >>>>> +} >>>>=20 >>>> I'd like to propose an alternative implementation that doesn't = require >>>> exposing the mem_section. The idea is to add a new helper function, >>>> pfn_to_section_order(), so that for non-sparse-memory = configurations, >>>> the mem_section concept stays hidden internally. I'd really = appreciate >>>> any thoughts or concerns =E2=80=94 if everyone is comfortable with = it, I can go >>>> ahead and implement this in the next version. >>>=20 >>> A helper that keeps mem_section hidden from !SPARSMEM makes perfect >>> sense to me. >>>=20 >>> I'd even take it one step further and make it return how many pfns >>> should be skipped in pfn_vmemmap_optimizable case. >>=20 >> To make sure we're on the same page, let me walk you through the = specific >> changes I have in mind. My initial plan is to introduce = pfn_to_section_order, >> and the expected diff changes are as follow to keep mem_sectionhidden = from >> !SPARSEMEM. >>=20 >> diff --git a/mm/mm_init.c b/mm/mm_init.c >> index dcb757b36902..0b0c2996d080 100644 >> --- a/mm/mm_init.c >> +++ b/mm/mm_init.c >> @@ -884,7 +884,7 @@ void __meminit memmap_init_range(unsigned long = size, int nid, unsigned long zone >> } >>=20 >> if (pfn_vmemmap_optimizable(pfn)) { >> - unsigned int order =3D = section_order(__pfn_to_section(pfn)); >> + unsigned int order =3D = pfn_to_section_order(pfn); >>=20 >> pfn =3D min(ALIGN(pfn, 1UL << order), = end_pfn); >> continue; >> diff --git a/mm/sparse.h b/mm/sparse.h >> index 030248030dc7..c5fbcdde3cee 100644 >> --- a/mm/sparse.h >> +++ b/mm/sparse.h >> @@ -47,6 +47,11 @@ static inline void __section_mark_present(struct = mem_section *ms, >>=20 >> ms->section_mem_map |=3D SECTION_MARKED_PRESENT; >> } >> + >> +static inline unsigned int pfn_to_section_order(unsigned long pfn) >> +{ >> + return section_order(__pfn_to_section(pfn)); >> +} >> #else >> static inline void sparse_init(void) {} >> #endif /* CONFIG_SPARSEMEM */ >>=20 >> Since we also use __pfn_to_section in the patch 14 in this series for >=20 > I still didn't get to patch 14 :) >=20 >> !SPARSEMEM, we need to make corresponding adjustments=E2=80=94specifica= lly, by using >> pfn_to_section_order to determine whether the vmemmap of a given = section is >> optimizable. This new helper will be called from several places, so = I'm afraid >> its introduction is unavoidable. >=20 > Do you mean that section_vmemmap_optimizable() will receive pfn as a > parameter and use pfn_to_section_order() internally? I was originally planning to go with the this approach, but now I've = come across something that feels a bit unusual to me: a function whose name starts = with section takes a pfn as its argument instead of a mem_section. So I started thinking about an alternative. How about we keep = section_vmemmap_optimizable() as it is, but introduce a new helper like this: static inline bool order_vmemmap_optimizable(unsigned int order) { return order >=3D OPTIMIZABLE_FOLIO_MIN_ORDER; } The main reason I'm leaning toward this design is that this new helper = would be useful in at least three places: - Inside section_vmemmap_optimizable(), we can use it to decide whether = a section is optimizable: static inline bool section_vmemmap_optimizable(const struct = mem_section *section) { if (!is_power_of_2(sizeof(struct page))) return false; return = order_vmemmap_optimizable(section_order(section)); } - In patch 14, we can call = order_vmemmap_optimizable(pfn_to_section_order(pfn)) to make the same kind of check. - Looking ahead, I'm hoping to unify HugeTLB's optimization checks under = this same helper as part of my broader refactoring plan =E2=80=94 which = would also allow us to remove some HugeTLB-specific code. For example: static inline bool hugetlb_vmemmap_optimizable(const struct = hstate *h) { return order_vmemmap_optimizable(huge_page_order(h)); } I'd really appreciate your thoughts on this =E2=80=94 does this approach = make sense to you? Thanks Muchun >=20 > If that's the case and pfn_to_section_order() will be used in several > places I think it's better than to have a dedicated helper just for > memmap_init_range(). >=20 >> That said, I've also considered an alternative: introducing another = helper that >> returns the exact number of PFNs to skip, and using it solely within >> memmap_init_range(). However, that approach doesn't seem to offer = much in terms >> of code simplification. If I'm missing something or if my reasoning = doesn't align >> with your expectations, I would really appreciate your guidance. = Thank you for >> your patience! >>=20 >> Thanks, >> Muchun >>=20 >>=20 >>=20 >=20 > --=20 > Sincerely yours, > Mike.