From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 3EAD13BCD16 for ; Thu, 16 Jul 2026 07:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784187555; cv=none; b=syCUJT4Twn9HDl4HRg2QpPAcJTC5ARmDqhSux3cX/G/hXw1p+wKgSqEhunPYNVuoUPk/s4H9xCC/BgNR9y7SokgBySGiKhUg9BjFDvkMWmWuBb8AZeLUs/YEKWvULVqZRLUSHyE9xGMwugMVVXFduqFp/xf7gl5OHjz4Tz9VVgE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784187555; c=relaxed/simple; bh=+H2Wxt9ixQa9fQzundMhgSv8va36GDvY76EgI3ouOk8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V8pc1sB2w++sOb3V5ezHjog6RKOVEoKRg+3DfqqT1VpIWKM0nWGpV0C1G/ZaPnOr5nUmVuNWiuYkgoHdmuthGZqM+NJpxjxMh4kUHHyzaBUZGfR9VqeH5b1KpyGIIgxlMpzBk6Xc6iseW4Mw8INDKWwUuT8+XmSOb9OasyLf8vQ= 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=Xd/7hvVd; arc=none smtp.client-ip=91.218.175.171 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="Xd/7hvVd" Message-ID: <8dab2dd9-1e0e-4254-b46c-cfe7a12cdea3@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784187547; 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=P4OfYWhrMY5vUIo3zsyfi7UAIQy6HkZks9t3XooeYn0=; b=Xd/7hvVd/NgbCgsjelKFWDee1lZosOcT0GKxeFaboUKDqsZw5wLcBtZHq4LjbcgVbl6wQV xfvmGd22tMIMGnSfx8x1Kvud94ee0Q/ARxCVhNIUPM09WD89ZQ3/k+VHxHuZH9E1CbPnXh sc5/mqCV+10J8FlBNHUj2sBYxYmc/pM= Date: Thu, 16 Jul 2026 15:38:59 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 03/17] mm/sparse-vmemmap: introduce folio-oriented vmemmap optimization macros To: Mike Rapoport Cc: Andrew Morton , Oscar Salvador , David Hildenbrand , linux-mm@kvack.org, Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , linux-kernel@vger.kernel.org, Muchun Song References: <20260702093821.2740183-1-songmuchun@bytedance.com> <20260702093821.2740183-4-songmuchun@bytedance.com> <178409212283.638342.14256193145803309214.b4-review@b4> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <178409212283.638342.14256193145803309214.b4-review@b4> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/7/15 13:08, Mike Rapoport wrote: >> Introduce macros for those folio-oriented properties and use them to >> replace the tail-based names in the HVO paths. This makes the code read >> in terms of folio semantics instead of an implementation detail and >> better matches other folio-based users such as DAX. >> >> No functional change intended. >> >> Signed-off-by: Muchun Song >> >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >> index bacd89572c5c..ea884245f499 100644 >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -107,13 +107,15 @@ >> is_power_of_2(sizeof(struct page)) ? \ >> MAX_FOLIO_NR_PAGES * sizeof(struct page) : 0) >> >> -/* >> - * vmemmap optimization (like HVO) is only possible for page orders that fill >> - * two or more pages with struct pages. >> - */ >> -#define VMEMMAP_TAIL_MIN_ORDER (ilog2(2 * PAGE_SIZE / sizeof(struct page))) >> -#define __NR_VMEMMAP_TAILS (MAX_FOLIO_ORDER - VMEMMAP_TAIL_MIN_ORDER + 1) >> -#define NR_VMEMMAP_TAILS (__NR_VMEMMAP_TAILS > 0 ? __NR_VMEMMAP_TAILS : 0) >> +/* The number of vmemmap pages required by a vmemmap-optimized folio. */ >> +#define OPTIMIZED_FOLIO_VMEMMAP_PAGES 1 >> +#define OPTIMIZED_FOLIO_VMEMMAP_SIZE (OPTIMIZED_FOLIO_VMEMMAP_PAGES * PAGE_SIZE) >> +#define OPTIMIZED_FOLIO_VMEMMAP_NR_STRUCT_PAGES (OPTIMIZED_FOLIO_VMEMMAP_SIZE / sizeof(struct page)) >> +#define OPTIMIZABLE_FOLIO_MIN_ORDER (ilog2(OPTIMIZED_FOLIO_VMEMMAP_NR_STRUCT_PAGES) + 1) >> + >> +#define __NR_OPTIMIZABLE_FOLIO_ORDERS (MAX_FOLIO_ORDER - OPTIMIZABLE_FOLIO_MIN_ORDER + 1) >> +#define NR_OPTIMIZABLE_FOLIO_ORDERS \ >> + (__NR_OPTIMIZABLE_FOLIO_ORDERS > 0 ? __NR_OPTIMIZABLE_FOLIO_ORDERS : 0) > I can't say I like the new names, they read like some folio optimization > rather than vmemmap optimization. > > I think they should be namespaced with VMEMMAP_ or even > VMEMMAP_OPTIMIZATION_ (or VMEMMAP_OPT_) and should not mention folio. If you're okay with it, I'll update those macros to: VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES VMEMMAP_OPTIMIZATION_MIN_ORDER VMEMMAP_OPTIMIZATION_NR_ORDERS > > I'd also drop intermediate defines OPTIMIZED_FOLIO_VMEMMAP_PAGES and > OPTIMIZED_FOLIO_VMEMMAP_SIZE and use 1 and PAGE_SIZE directly. OK. I'll not introduce OPTIMIZED_FOLIO_VMEMMAP_PAGES and OPTIMIZED_FOLIO_VMEMMAP_SIZE Muchun, Thanks.