From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 6493520ADF8 for ; Wed, 15 Jul 2026 06:43:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784097818; cv=none; b=s6tFKCc9iSrYck8F3hKRu18Hgv6ykRkAftVXuXd6TEu2OD56soo8QeEi/oFH8Y7ZBw8RCHefWHU788AXHnBvH+mkOPBpLrQxfTOvKt/I2H+FGZAtqBarlM21gl2smCh1uWYTs/sTu+LK6zBaGYHHXdwjRVzkgeLh4/Fd+44nnho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784097818; c=relaxed/simple; bh=SPWQaWig10gwCU8T+wwaziDdRkGTCsiCp3qQAHwlYRw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=dPZ82O/MeKcSFT45nYMdCCPFGZXNEpw2BkHsrHbt/mkIoXtVYCJZP3ZqqtsB2f+MXcEK6fZAT5waZHdp9zm3D6IcorH8seNu4RXhBDbTVrUdNNF77UkH72FjqU9AJWWx6hJi44+kLOqsiyNzgGQqheWxij85aw35q24fyThDwgg= 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=Al0yGkNE; arc=none smtp.client-ip=91.218.175.189 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="Al0yGkNE" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784097812; 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=Cf9KdbDpjwwk3lvfV0bJrHjUpq8gemkP35I5oZ9Pf/0=; b=Al0yGkNEEx2n/z0BLAOUTCfHBBtYltBiiyKxYTkooN7fT+80kvNLbEdfTijJJ+aYQrE+kq JrIkAOfNRj3SYAwBOcdZpBgNukw4VeBompiwNWsio2BpT6UkjvZT0jHonsotLNnywfrEbh 9ECOSXC5S1qZaipYIjrvntiGpnap0U4= 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 02/17] mm/sparse-vmemmap: track compound page order in struct mem_section X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <178409212283.638342.5794416106269994417.b4-review@b4> Date: Wed, 15 Jul 2026 14:42:56 +0800 Cc: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand , linux-mm@kvack.org, Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260702093821.2740183-1-songmuchun@bytedance.com> <20260702093821.2740183-3-songmuchun@bytedance.com> <178409212283.638342.5794416106269994417.b4-review@b4> To: Mike Rapoport X-Migadu-Flow: FLOW_OUT > On Jul 15, 2026, at 13:08, Mike Rapoport wrote: >=20 >> HugeTLB and DAX both rely on vmemmap optimization, but sparsemem does >> not record what compound page order a section is populated with. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Signed-off-by: Muchun Song >>=20 >> 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. >> + */ >=20 > Typically a section holds order-0 pages ;-) >=20 > 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? >=20 >> + unsigned int order; >> +#endif >> }; >>=20 >> #ifdef CONFIG_SPARSEMEM_EXTREME >> @@ -2361,10 +2369,34 @@ static inline unsigned long = next_present_section_nr(unsigned long section_nr) >> #endif >>=20 >> #else >> +struct mem_section; >> + >> #define sparse_vmemmap_init_nid_early(_nid) do {} while (0) >> #define pfn_in_present_section pfn_valid >> #endif /* CONFIG_SPARSEMEM */ >>=20 >> +#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 !=3D = order); >> + section->order =3D order; >> +} >> + >> +static inline unsigned int section_order(const struct mem_section = *section) >> +{ >> + return section->order; >> +} >=20 > 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. >=20 > 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. >=20 > --=20 > Sincerely yours, > Mike.