From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 A1BEB413D8F for ; Thu, 30 Jul 2026 14:32:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785421952; cv=none; b=jVMWe74Snp9RE0byKe11+3MK/yoBxtERU3jbq8mOG3QLaB3BOzUAEgehIu8Ay4WzGHgfgaZR2k4ycZMnhSmWVWjKlR9FTMKA59y6O9Is8Io0m1nxa4zSvS44eEwEv9vUw5oH6+KefZV9EEHkNQ31k4V+dphruhnBDnMyxCWO13c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785421952; c=relaxed/simple; bh=WB3iGY73aCnZD9ybmcDav9+eloNmI+poj8kOc45RjjE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eIK1aX04/MFe14VtMDPJRHcBa3tBiysDTp8W0ih3fx41QynIAzeyEKlW0JACdSo7aR9yFxHHQdOcrEEb9/NCa3qql8l4+CXJpUV9EFAjovkCHLjBfm2im7VOnyfFlg1Kl5bm0e2NwdeQagktlOoWbb62vcoZqR2QHGB53gJxf3w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FgbDucpS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FgbDucpS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D83131F00A3D; Thu, 30 Jul 2026 14:32:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785421949; bh=TlCg4hKA/4zkmMDzGtbzJKj4HELVTyv3d6KsqoYYXlo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FgbDucpS4lw76IR0ZcU1uGDuE8Fx14VLpEA6jvtHNDM4eY6aznNPUex9EOsFI4D3Y dhcvOkkwO4vFGyDILA8B8ttQTsgtcTYqM+pJSvk7UiKED7DVeJXxjzk8PP5O+Zf+ev cFGFuYOjiZzP0Q2dx+4VpLB0hIqRzgHO1J3prfl95xqTvEfKRBDxhZaVYYCUC74IEt 8/+1XmjnyrTrNNyG3Fb6d0c5eKi8fzEUfm33rOs4Y2jaxc5/tTMPkvrVWhvPR/u4Vp 3BVln8kD0GBclyE2jzuh578TdsBB6Rb1mk2VzsdDB1HmqiZj3MWsa9K/pomAdFrvVh JDMIZqv8XP8Dg== Date: Thu, 30 Jul 2026 17:32:21 +0300 From: Mike Rapoport To: Muchun Song 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 Subject: Re: [PATCH v2 03/17] mm/mm_init: skip initializing shared vmemmap tail pages Message-ID: 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3FCC8989-95DB-450F-95C3-183787DF4D08@linux.dev> 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: > >>> > >>> #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; > >>> +} > >> > >> 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 — if everyone is comfortable with it, I can go > >> ahead and implement this in the next version. > > > > A helper that keeps mem_section hidden from !SPARSMEM makes perfect > > sense to me. > > > > I'd even take it one step further and make it return how many pfns > > should be skipped in pfn_vmemmap_optimizable case. > > 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. > > 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 > } > > if (pfn_vmemmap_optimizable(pfn)) { > - unsigned int order = section_order(__pfn_to_section(pfn)); > + unsigned int order = pfn_to_section_order(pfn); > > pfn = 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, > > ms->section_mem_map |= 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 */ > > Since we also use __pfn_to_section in the patch 14 in this series for I still didn't get to patch 14 :) > !SPARSEMEM, we need to make corresponding adjustments—specifically, 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. Do you mean that section_vmemmap_optimizable() will receive pfn as a parameter and use pfn_to_section_order() internally? 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(). > 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! > > Thanks, > Muchun > > > -- Sincerely yours, Mike.