mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Lance Yang <lance.yang@linux.dev>
Cc: osalvador@suse.de, akpm@linux-foundation.org, rppt@kernel.org,
	qi.zheng@linux.dev, jthoughton@google.com, david@kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Muchun Song <songmuchun@bytedance.com>
Subject: Re: [PATCH 07/12] mm: hugetlb_vmemmap: simplify shared tail page handling
Date: Fri, 23 Oct 2026 10:32:05 +0800	[thread overview]
Message-ID: <a340ec5a-c50b-4fa3-b325-52dba86f0015@linux.dev> (raw)
In-Reply-To: <20261023022027.25898-1-lance.yang@linux.dev>



On 2026/10/23 10:20, Lance Yang wrote:
> On Tue, Oct 20, 2026 at 07:58:19PM +0800, Muchun Song wrote:
>> The remap walker currently carries a shared tail page selected by its
>> caller, even though the optimize and restore callbacks can derive the
>> same information from the folio being processed.  This adds redundant
>> state to the walker and couples its interface to caller-side preparation.
>>
>> Derive the shared mapping state in the callbacks instead, keeping the
>> mapping policy with the PTE being processed and simplifying the remap
>> interface.
>>
>> No functional change intended.
>>
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>> include/linux/vmemmap-optimization.h |  6 +-
>> mm/hugetlb_vmemmap.c                 | 89 ++++++++++++----------------
>> mm/mm_init.c                         |  6 +-
>> mm/sparse-vmemmap.c                  |  5 +-
>> 4 files changed, 49 insertions(+), 57 deletions(-)
>>
>> diff --git a/include/linux/vmemmap-optimization.h b/include/linux/vmemmap-optimization.h
>> index 065840f3c241..858311a71b0c 100644
>> --- a/include/linux/vmemmap-optimization.h
>> +++ b/include/linux/vmemmap-optimization.h
>> @@ -91,11 +91,13 @@ static inline struct page *vmemmap_shared_tail_page(unsigned int order,
>> }
>> #endif /* CONFIG_VMEMMAP_OPTIMIZATION */
>>
>> -static inline bool vmemmap_optimizable_pfn(unsigned long pfn)
>> +static inline bool vmemmap_optimizable_pfn(unsigned long pfn, unsigned int order)
>> {
>> -	const unsigned int order = pfn_to_section_compound_order(pfn);
>> 	const unsigned long nr_pages = 1UL << order;
>>
>> +	if (!IS_ENABLED(CONFIG_VMEMMAP_OPTIMIZATION))
>> +		return false;
>> +
>> 	if (!is_power_of_2(sizeof(struct page)))
>> 		return false;
>>
>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
>> index 18b72d553955..8fac61b7d74a 100644
>> --- a/mm/hugetlb_vmemmap.c
>> +++ b/mm/hugetlb_vmemmap.c
>> @@ -24,22 +24,18 @@
>>   * struct vmemmap_remap_walk - walk vmemmap page table
>>   *
>>   * @remap_pte:		called for each lowest-level entry (PTE).
>> - * @nr_walked:		the number of walked pte.
>> - * @vmemmap_tail:	the page to be installed as non-first in the vmemmap range
>> + * @nr_walked:		the number of PTEs successfully remapped.
>>   * @vmemmap_pages:	the list head of the vmemmap pages that can be freed
>>   *			or is mapped from.
>>   * @flags:		used to modify behavior in vmemmap page table walking
>>   *			operations.
>>   */
>> struct vmemmap_remap_walk {
>> -	void			(*remap_pte)(pte_t *pte, unsigned long addr,
>> +	int			(*remap_pte)(pte_t *pte, unsigned long addr,
>> 					     struct vmemmap_remap_walk *walk);
>> -
>> 	unsigned long		nr_walked;
>> -	struct page		*vmemmap_tail;
>> 	struct list_head	*vmemmap_pages;
>>
>> -
>> /* Skip the TLB flush while updating the vmemmap page tables. */
>> #define VMEMMAP_REMAP_NO_TLB_FLUSH	BIT(0)
>> 	unsigned long		flags;
>> @@ -140,12 +136,14 @@ static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr,
>> static int vmemmap_pte_entry(pte_t *pte, unsigned long addr,
>> 			     unsigned long next, struct mm_walk *walk)
>> {
>> +	int ret;
>> 	struct vmemmap_remap_walk *vmemmap_walk = walk->private;
>>
>> -	vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
>> -	vmemmap_walk->nr_walked++;
>> +	ret = vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
>> +	if (!ret)
>> +		vmemmap_walk->nr_walked++;
>>
>> -	return 0;
>> +	return ret;
>> }
>>
>> static const struct mm_walk_ops vmemmap_remap_ops = {
>> @@ -213,51 +211,51 @@ static struct page *vmemmap_dup_page_from_list(const struct page *src,
>> 	return dst;
>> }
>>
>> -static void vmemmap_optimize_pte(pte_t *pte, unsigned long addr,
>> -				 struct vmemmap_remap_walk *walk)
>> +static inline struct page *folio_vmemmap_shared_tail_page(const struct folio *folio)
>> {
>> -	struct page *page = pte_page(ptep_get(pte));
>> -	pte_t entry;
>> -
>> -	/* Remapping the head page requires r/w */
>> -	if (unlikely(walk->nr_walked == 0)) {
>> -		struct page *head;
>> +	return vmemmap_shared_tail_page(folio_order(folio), folio_zone(folio));
>> +}
>>
>> -		VM_WARN_ON_ONCE(!PageHead((const struct page *)addr));
>> +static int vmemmap_optimize_pte(pte_t *pte, unsigned long addr,
>> +				struct vmemmap_remap_walk *walk)
>> +{
>> +	pte_t entry;
>> +	struct page *src = pte_page(ptep_get(pte)), *dst;
>> +	const struct page *page = (const struct page *)addr;
>> +	const struct folio *folio = page_folio(page);
>>
>> -		head = vmemmap_dup_page_from_list(page, walk->vmemmap_pages);
>> -		entry = mk_pte(head, PAGE_KERNEL);
>> +	if (likely(vmemmap_optimizable_pfn(page_to_pfn(page), folio_order(folio)))) {
>> +		dst = folio_vmemmap_shared_tail_page(folio);
>> +		if (!dst)
>> +			return -ENOMEM;
> One thing caught my eye here ... shared tail allocation can now fail after
> we've already remapped the head.

Right. Once the shared page has been allocated successfully, this
shouldn't be a common case.

>
> IIUC, nothing to worry about there, though :) since rollback keeps the
> new head mapped and flushes before clearing the optimized flag or freeing
> the old backing page.

Yes.

>
> [...]
>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>

Thanks.

  reply	other threads:[~2026-10-23  2:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 11:52 [PATCH 00/12] mm: Decouple folio-based vmemmap optimization from HugeTLB Muchun Song
2026-10-20 11:52 ` [PATCH 01/12] mm: hugetlb_vmemmap: remove HugeTLB-specific vmemmap optimization macros Muchun Song
2026-10-22  3:43   ` Lance Yang
2026-10-20 11:58 ` [PATCH 02/12] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Muchun Song
2026-10-20 11:58   ` [PATCH 03/12] mm: hugetlb_vmemmap: simplify vmemmap head page handling Muchun Song
2026-10-22  6:24     ` Lance Yang
2026-10-22  6:27       ` Muchun Song
2026-10-22  7:23     ` Lance Yang
2026-10-20 11:58   ` [PATCH 04/12] mm: hugetlb_vmemmap: generalize vmemmap page allocation Muchun Song
2026-10-22 13:54     ` Lance Yang
2026-10-20 11:58   ` [PATCH 05/12] mm: hugetlb_vmemmap: unify writable vmemmap page preparation Muchun Song
2026-10-22 14:13     ` Lance Yang
2026-10-20 11:58   ` [PATCH 06/12] mm: hugetlb_vmemmap: rename vmemmap_remap_pte() to vmemmap_optimize_pte() Muchun Song
2026-10-23  0:55     ` Lance Yang
2026-10-20 11:58   ` [PATCH 07/12] mm: hugetlb_vmemmap: simplify shared tail page handling Muchun Song
2026-10-23  2:20     ` Lance Yang
2026-10-23  2:32       ` Muchun Song [this message]
2026-10-20 11:58   ` [PATCH 08/12] mm: hugetlb_vmemmap: move alloc_vmemmap_page_list() next to its free helper Muchun Song
2026-10-23  2:47     ` Lance Yang
2026-10-20 11:58   ` [PATCH 09/12] mm: hugetlb_vmemmap: make vmemmap optimization folio-oriented Muchun Song
2026-10-23  3:39     ` Lance Yang
2026-10-20 11:58   ` [PATCH 10/12] mm: hugetlb_vmemmap: make vmemmap restoration folio-oriented Muchun Song
2026-10-23  3:46     ` Lance Yang
2026-10-23  3:58       ` Muchun Song
2026-10-20 11:58   ` [PATCH 11/12] mm: hugetlb_vmemmap: unify vmemmap range restoration Muchun Song
2026-10-23  3:53     ` Lance Yang
2026-10-20 11:58   ` [PATCH 12/12] mm: hugetlb_vmemmap: make vmemmap PTE conversion folio-oriented Muchun Song
2026-10-22  3:52   ` [PATCH 02/12] mm: hugetlb_vmemmap: unify VMEMMAP_{SPLIT,REMAP}_NO_TLB_FLUSH Lance Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a340ec5a-c50b-4fa3-b325-52dba86f0015@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=jthoughton@google.com \
    --cc=lance.yang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=qi.zheng@linux.dev \
    --cc=rppt@kernel.org \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®