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: 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®