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 25A7D423763 for ; Wed, 15 Jul 2026 09:45:27 +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=1784108735; cv=none; b=Ul0xSQ0YtjCOheRsG3piVer3fBfyKtPayaBFGHQFalbOnuT5awl4JZvBQ/SZs+kYd3dAMbgTCZhuk0uHoAqCMBzKWQHbc4+hI9Ka9afX0cKBFNp51C09ci0czIR68je8lv1JXOZoL+Ml4jyKB37S8czErnvNRLCW4s1SlL/DmjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784108735; c=relaxed/simple; bh=LwtPsWPTAfSwqUCy6fPgEOlqQQpTI69X1Das5uBQ7rM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ECtcZQhS1klHFRRMrRh8HW7qwUTcBZLdvvAMLlX1kLYgvnC74YYH28F+dbaDek2iLijwuRteHJ7VThgkD36VRMypXAoS51qLV4bHON72eaVpoBW68LM4Q/HrHeylzElg8tfz30BpGx8SBORNE36PROVELeB1u4OpQFuqwJCmcag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D2VYLWr2; 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="D2VYLWr2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F4AB1F000E9; Wed, 15 Jul 2026 09:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784108725; bh=JxJvz4NZjuPGVoz4ImdV89WWqkSZ4igSVcaiNURZ+14=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=D2VYLWr2pSiuiG7EHFxOt5exQmzdclrNB5l4jug8phpoabQyBPzD0GGXVIsxlOnj5 ynMk/WUSM9r21kooQW3sHP+LEAcsyH+4HlcqM3mLJvOC2MqGOvcZnZ3v9T1VX4vmTV Aug0DMBv20cIo8Is515N2XKbkY2T2Q1ggd13YGoMUS/acbpJ9Ny1WOzTDToFly/x6/ KBtYcuuLjnnf8SXusB49rbjyukmKdn76KmHF1DPZ5YLB7UJwINgQt40JErkBNb3JR6 Lm5tQo29y+uZXneEVTN/5rKGRToLyma3oOJOHVravmS2CjUR1VGmkPZFRc7GIoohnm oCYAXWHAVBk6w== Date: Wed, 15 Jul 2026 12:45:18 +0300 From: Mike Rapoport To: Muchun Song Cc: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand , linux-mm@kvack.org, Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/17] mm/sparse-vmemmap: track compound page order in struct mem_section Message-ID: References: <20260702093821.2740183-1-songmuchun@bytedance.com> <20260702093821.2740183-3-songmuchun@bytedance.com> <178409212283.638342.5794416106269994417.b4-review@b4> 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=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jul 15, 2026 at 02:42:56PM +0800, Muchun Song wrote: > > > > On Jul 15, 2026, at 13:08, Mike Rapoport wrote: > > > >> HugeTLB and DAX both rely on vmemmap optimization, but sparsemem does > >> not record what compound page order a section is populated with. > >> > >> As a result, code that needs this information has to open-code > >> separate handling across users of vmemmap optimization. It also > >> prevents other memory management code, such as struct page > >> initialization, from skipping initialization of shared vmemmap pages > >> when needed. > >> > >> Track the compound page order in struct mem_section and provide small > >> helpers to access it. A compound page larger than a section naturally > >> carries the same order across all covered sections. > >> > >> This is a preparatory change for consolidating vmemmap optimization > >> handling and for letting later code make initialization decisions > >> based on the section's compound page order. > >> > >> Signed-off-by: Muchun Song > >> > >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >> index 1353bcf7b712..bacd89572c5c 100644 > >> --- a/include/linux/mmzone.h > >> +++ b/include/linux/mmzone.h > >> @@ -2015,6 +2015,14 @@ struct mem_section { > >> */ > >> struct page_ext *page_ext; > >> #endif > >> +#ifdef CONFIG_SPARSEMEM_VMEMMAP > >> + /* > >> + * The order of compound pages in this section. Typically, the section > >> + * holds compound pages of this order; a larger compound page will span > >> + * multiple sections. > >> + */ > > > > Typically a section holds order-0 pages ;-) > > > > I think this comment should mention that this is for special sections, > > like hugetlb and DAX. > > I will update the comment to focus on the general concept of HVO as follows: > > Normally, sections hold regular (order-0) pages. However, for > sections with HVO enabled, this tracks the compound page order > to enable deduplication of redundant vmemmap pages. > > How does this look to you? LGTM, thanks! > >> + unsigned int order; > >> +#endif > >> }; > >> > >> #ifdef CONFIG_SPARSEMEM_EXTREME > >> @@ -2361,10 +2369,34 @@ static inline unsigned long next_present_section_nr(unsigned long section_nr) > >> #endif > >> > >> #else > >> +struct mem_section; > >> + > >> #define sparse_vmemmap_init_nid_early(_nid) do {} while (0) > >> #define pfn_in_present_section pfn_valid > >> #endif /* CONFIG_SPARSEMEM */ > >> > >> +#ifdef CONFIG_SPARSEMEM_VMEMMAP > >> +static inline void section_set_order(struct mem_section *section, unsigned int order) > >> +{ > >> + VM_WARN_ON(section->order && order && section->order != order); > >> + section->order = order; > >> +} > >> + > >> +static inline unsigned int section_order(const struct mem_section *section) > >> +{ > >> + return section->order; > >> +} > > > > You mention open-coded handling, is there any open-coded case that can > > be replaced with the new helpers right away? > > The term "open-code" in my commit message might not have been clear enough. > > What I intended to convey is that because HVO lacks this specific layer of > information in both DAX and HugeTLB scenarios, they each handle their own > cases independently. As a result, there isn't enough code reuse. > > Thank you so much for pointing that out. > > > > > We strive to have new APIs and at least some of their users in the same > > patch. > > All right. Starting with the next version, I'll be introducing the necessary > fields (i.e. ->order) or interfaces here into each of the upcoming patches. > In that case, this patch should no longer exist. > > Muchun, > Thanks. > > > > > -- > > Sincerely yours, > > Mike. > > -- Sincerely yours, Mike.