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 7EE241A2545 for ; Thu, 16 Jul 2026 06:24:06 +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=1784183047; cv=none; b=cVKtGj+9zob1TzxNSCxeR7vewQk5KWMoBc7J7Q9t65vKIV0JHIHZCgfpDR6U59PbHmBq0DBFgmuNJB/pz6geRrj7aovrY3TNpILZ4VYRt9o4Lo2hGPg+GWoCl2H4uLSx7z4Csy+0IcESjMpGUe952rBDTBkFmoC+pwgfSmw4aiA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784183047; c=relaxed/simple; bh=/prnoawE/dVLAq2+5w7VjoKQQr8d+isEzK61lbY/hWc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Vxjm9bN48ArbO0xUuqFAfQvTjBU1rwcIe41EydcB8WlbBYOww0kfo5ktAbV84l0BQzgXZI3pCztuqCfeTSywDi+ZCSx0bqlXAguZg5cTVldfXDkCZx0bKxWMTGYAMSWZryqH9ElNjn6BYilnZk1uoR6Ylv57Xl+9MvPwBIcz+k0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OpifRso0; 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="OpifRso0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8610B1F000E9; Thu, 16 Jul 2026 06:24:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784183046; bh=FVe9urgPIdx0xvaLTwNFMJt8EywUvgB77c5UK+FxvSM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OpifRso0dGl92KlI0Xkk/PDlf8cWEBuQEgbOZY96h+qOZNoFid1MAD5W2YtdDgxYo dlPl/mxsgUt+j7c+ba7j/83lrLjnddAyDtYOrUyEfK9dj4FDmQeaTE1+X50kYwbBv5 WZMRWEYK2qTUEksaVCEBrGjnQrlrCf1PQsfI/x4pMKT/MQpZd8Q5pyH+rxA3q/EAZ6 y8GW+wKzNg4z7BqeGyYEj7pXjqKqlFkVrd7CgJSK2NLShyhXyyUP+OUq+wAa/4XJZv OLTmPza/J4WMVhGsHRRXI8+oErGwzXxwlwk9AzXFgMdxSXBDRaVjytEOg7hXSjXWm5 TqcvD1i2/uY1w== Date: Thu, 16 Jul 2026 09:23:59 +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 06/17] mm/sparse-vmemmap: support section-based vmemmap accounting Message-ID: References: <20260702093821.2740183-1-songmuchun@bytedance.com> <20260702093821.2740183-7-songmuchun@bytedance.com> <178409212283.638342.6610895811767474932.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 10:44:51PM +0800, Muchun Song wrote: > > On Jul 15, 2026, at 13:08, Mike Rapoport wrote: > > > >> section_nr_vmemmap_pages() is used to account the vmemmap pages consumed by a > >> memory section, but it currently only understands the ordinary case and the > >> pgmap-provided optimization case. That is not enough for section-based vmemmap > >> optimization, where the compound page order is carried by the memory section > >> itself and tail vmemmap pages may be shared. > >> > >> Make the helper report the actual vmemmap footprint of a section, so it can be > >> used as the common accounting path for both ordinary and optimized sections. > >> > >> Teach section_nr_vmemmap_pages() to use the section order when there is no > >> pgmap, and to account only the vmemmap pages that are actually needed for an > >> optimizable section. This keeps the accounting consistent with section-based > >> vmemmap optimization. > >> > >> Signed-off-by: Muchun Song > >> > >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >> index 6fa6e7f0abf9..41a1ebbe5e85 100644 > >> --- a/include/linux/mmzone.h > >> +++ b/include/linux/mmzone.h > >> @@ -2403,6 +2403,14 @@ static inline unsigned int section_order(const struct mem_section *section) > >> } > >> #endif > >> > >> +static inline bool section_vmemmap_optimizable(const struct mem_section *section) > >> +{ > >> + if (!is_power_of_2(sizeof(struct page))) > >> + return false; > >> + > >> + return section_order(section) >= OPTIMIZABLE_FOLIO_MIN_ORDER; > > > > Like with page_vmemmap_optimizable() I think it's not obvious that > > section_order() is enough to gate vmemmap optimization. > > page_vmemmap_optimizable() checks the optimizability of an individual page. > section_vmemmap_optimizable() checks whether the optimization can be applied > to a section. Some people may think that section_vmemmap_optimizable() checks > the optimizability of all pages within an entire section. You are referring > to that ambiguity, right? > > What do you think about renaming it to section_vmemmap_optimization_eligible()? > Would that clear up the ambiguity? Or should we add a comment to > section_vmemmap_optimizableto explain its purpose? The name is fine, IMHO. What I meant is that it would be clearer if there was a check for HUGETLB_PAGE_OPTIMIZE_VMEMMAP. -- Sincerely yours, Mike.