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.
next prev parent reply other threads:[~2026-10-23 2:32 UTC|newest]
Thread overview: 29+ 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-23 7:33 ` Lance Yang
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.