Hugetlb currently expands MMU notifier ranges to PUD boundaries whenever
PMD sharing is possible. That is only needed when huge_pmd_unshare()
actually detaches a shared PMD page table, because clearing the PUD
invalidates the whole PUD-sized virtual address range.

For hugetlbfs hole punch, and similarly for other hugetlb unmap paths,
a shared mapping can pass the "PMD sharing is possible" range test in
adjust_range_if_pmd_sharing_possible() even when the hugetlbfs file has
never actually had any shared PMD page tables. KVM then receives a 1G
invalidation for a 2M operation and zaps unrelated secondary mappings,
so the guest has to fault them back in.

Avoid this by remembering, per hugetlbfs inode, whether PMD sharing was
ever established for the file. Set the flag when huge_pmd_share()
successfully populates a shared PMD table. For the hugetlb unmap paths,
skip the conservative PUD-sized notifier expansion while the file has
never seen PMD sharing.

The state is intentionally sticky and file-wide. Once PMD sharing has
ever happened for the file, the unmap paths keep the existing
conservative expansion. This avoids the no-sharing case without adding a
page-table walk to every unmap.

On a Redis-in-VM workload that punches cold 2M hugetlb pages, this patch
improves P99 QPS stability while punching pages, reducing the QPS
degradation ratio from 7.09% to 1.45%.

Reported-by: aiqi.i7 <aiqi.i7@bytedance.com>
Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
---
v1: https://lore.kernel.org/all/20260831091023.66581-1-lizhe.67@bytedance.com/

ChangeLogs:
- Rework the implementation based on David's suggestion: remember
  whether PMD sharing ever happened for a hugetlbfs file, and skip the
  conservative notifier range expansion while it has not. This avoids
  the per-unmap page-table walk.

 fs/hugetlbfs/inode.c    |  3 +++
 include/linux/hugetlb.h | 24 ++++++++++++++++++++++++
 mm/hugetlb.c            | 11 ++++++++---
 3 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 7611a84..1e24b8d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -921,6 +921,9 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
 		simple_inode_init_ts(inode);
 		info->resv_map = resv_map;
 		info->seals = F_SEAL_SEAL;
+#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
+		info->pmd_sharing_seen = false;
+#endif
 		switch (mode & S_IFMT) {
 		default:
 			init_special_inode(inode, mode, dev);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 16c4c4c..8f1f899 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -509,6 +509,9 @@ struct hugetlbfs_inode_info {
 	struct inode vfs_inode;
 	struct resv_map *resv_map;
 	unsigned int seals;
+#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
+	bool pmd_sharing_seen;
+#endif
 };
 
 static inline struct hugetlbfs_inode_info *HUGETLBFS_I(struct inode *inode)
@@ -516,6 +519,27 @@ static inline struct hugetlbfs_inode_info *HUGETLBFS_I(struct inode *inode)
 	return container_of(inode, struct hugetlbfs_inode_info, vfs_inode);
 }
 
+#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
+static inline void hugetlbfs_set_pmd_sharing_seen(struct inode *inode)
+{
+	HUGETLBFS_I(inode)->pmd_sharing_seen = true;
+}
+
+static inline bool hugetlbfs_pmd_sharing_seen(struct inode *inode)
+{
+	return HUGETLBFS_I(inode)->pmd_sharing_seen;
+}
+#else
+static inline void hugetlbfs_set_pmd_sharing_seen(struct inode *inode)
+{
+}
+
+static inline bool hugetlbfs_pmd_sharing_seen(struct inode *inode)
+{
+	return false;
+}
+#endif
+
 extern const struct vm_operations_struct hugetlb_vm_ops;
 struct file *hugetlb_file_setup(const char *name, size_t size, vma_flags_t acct,
 				int creat_flags, int page_size_log);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7857728..e370960 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5359,10 +5359,12 @@ void __hugetlb_zap_begin(struct vm_area_struct *vma,
 	if (!vma->vm_file)	/* hugetlbfs_file_mmap error */
 		return;
 
-	adjust_range_if_pmd_sharing_possible(vma, start, end);
 	hugetlb_vma_lock_write(vma);
-	if (vma->vm_file)
+	if (vma->vm_file) {
 		i_mmap_lock_write(vma->vm_file->f_mapping);
+		if (hugetlbfs_pmd_sharing_seen(file_inode(vma->vm_file)))
+			adjust_range_if_pmd_sharing_possible(vma, start, end);
+	}
 }
 
 void __hugetlb_zap_end(struct vm_area_struct *vma,
@@ -5401,7 +5403,9 @@ void unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start,
 
 	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm,
 				start, end);
-	adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end);
+	if (hugetlbfs_pmd_sharing_seen(file_inode(vma->vm_file)))
+		adjust_range_if_pmd_sharing_possible(vma, &range.start,
+						     &range.end);
 	mmu_notifier_invalidate_range_start(&range);
 	tlb_gather_mmu(&tlb, vma->vm_mm);
 
@@ -7004,6 +7008,7 @@ pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 	if (pud_none(*pud)) {
 		pud_populate(mm, pud,
 				(pmd_t *)((unsigned long)spte & PAGE_MASK));
+		hugetlbfs_set_pmd_sharing_seen(mapping->host);
 		mm_inc_nr_pmds(mm);
 	} else {
 		ptdesc_pmd_pts_dec(virt_to_ptdesc(spte));
-- 
2.45.2

On Tue, 22 Sep 2026 17:07:49 +0800 "Li Zhe" <lizhe.67@bytedance.com> wrote:

> Hugetlb currently expands MMU notifier ranges to PUD boundaries whenever
> PMD sharing is possible. That is only needed when huge_pmd_unshare()
> actually detaches a shared PMD page table, because clearing the PUD
> invalidates the whole PUD-sized virtual address range.
> 
> For hugetlbfs hole punch, and similarly for other hugetlb unmap paths,
> a shared mapping can pass the "PMD sharing is possible" range test in
> adjust_range_if_pmd_sharing_possible() even when the hugetlbfs file has
> never actually had any shared PMD page tables. KVM then receives a 1G
> invalidation for a 2M operation and zaps unrelated secondary mappings,
> so the guest has to fault them back in.
> 
> Avoid this by remembering, per hugetlbfs inode, whether PMD sharing was
> ever established for the file. Set the flag when huge_pmd_share()
> successfully populates a shared PMD table. For the hugetlb unmap paths,
> skip the conservative PUD-sized notifier expansion while the file has
> never seen PMD sharing.
> 
> The state is intentionally sticky and file-wide. Once PMD sharing has
> ever happened for the file, the unmap paths keep the existing
> conservative expansion. This avoids the no-sharing case without adding a
> page-table walk to every unmap.

Oh.  It's not feasible to figure out when PMD sharing has ended and go
back to never-seen-sharing state?

> On a Redis-in-VM workload that punches cold 2M hugetlb pages, this patch
> improves P99 QPS stability while punching pages, reducing the QPS
> degradation ratio from 7.09% to 1.45%.

How realistic is this test?  IOW, how much benefit can people expect to
see in real-world usage?


> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -921,6 +921,9 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
>  		simple_inode_init_ts(inode);
>  		info->resv_map = resv_map;
>  		info->seals = F_SEAL_SEAL;
> +#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
> +		info->pmd_sharing_seen = false;
> +#endif

This could use a slightly modified hugetlbfs_set_pmd_sharing_seen() and
remove the ifdefs.

	hugetlbfs_set_pmd_sharing_seen(inode, false);

Not very important.

On 9/23/26 10:00 AM, Andrew Morton wrote:
> On Tue, 22 Sep 2026 17:07:49 +0800 "Li Zhe" <lizhe.67@bytedance.com> wrote:
>
>> Hugetlb currently expands MMU notifier ranges to PUD boundaries whenever
>> PMD sharing is possible. That is only needed when huge_pmd_unshare()
>> actually detaches a shared PMD page table, because clearing the PUD
>> invalidates the whole PUD-sized virtual address range.
>>
>> For hugetlbfs hole punch, and similarly for other hugetlb unmap paths,
>> a shared mapping can pass the "PMD sharing is possible" range test in
>> adjust_range_if_pmd_sharing_possible() even when the hugetlbfs file has
>> never actually had any shared PMD page tables. KVM then receives a 1G
>> invalidation for a 2M operation and zaps unrelated secondary mappings,
>> so the guest has to fault them back in.
>>
>> Avoid this by remembering, per hugetlbfs inode, whether PMD sharing was
>> ever established for the file. Set the flag when huge_pmd_share()
>> successfully populates a shared PMD table. For the hugetlb unmap paths,
>> skip the conservative PUD-sized notifier expansion while the file has
>> never seen PMD sharing.
>>
>> The state is intentionally sticky and file-wide. Once PMD sharing has
>> ever happened for the file, the unmap paths keep the existing
>> conservative expansion. This avoids the no-sharing case without adding a
>> page-table walk to every unmap.
> Oh.  It's not feasible to figure out when PMD sharing has ended and go
> back to never-seen-sharing state?


Yes, it is feasible.


I did consider a refcount-based approach before sending v2, but my
initial version looked more complicated than I was comfortable with.  So
I used the sticky state in v2 to keep the change simple and avoid adding
page-table walks to the unmap path.

After looking at this again, I think the refcounting can be kept
reasonably small.  The updated version uses a per-hugetlbfs-inode
counter for active PMD-sharing attachments.  The counter is incremented
only after huge_pmd_share() successfully installs a shared PMD table, and
is decremented when __huge_pmd_unshare() actually detaches one.

The share side can run concurrently under i_mmap_lock_read(), so the
counter uses atomic operations.  A zero count is used to skip the
PUD-sized notifier expansion only after excluding concurrent PMD sharing
with the mapping write lock.

Sorry for the churn; I will send v3 with this refcounting approach.

>> On a Redis-in-VM workload that punches cold 2M hugetlb pages, this patch
>> improves P99 QPS stability while punching pages, reducing the QPS
>> degradation ratio from 7.09% to 1.45%.
> How realistic is this test?  IOW, how much benefit can people expect to
> see in real-world usage?


This was measured on a KVM workload using hugetlbfs-backed guest memory.

The workload performs policy-driven 2M hugetlbfs unmaps while the guest
keeps running.  The important part is not the policy itself, but that a
2M hugetlbfs unmap can currently be reported to KVM as a 1G invalidation
when PMD sharing is only possible, but not actually active.

So the benefit is expected for workloads with secondary MMU users, such
as KVM, that see sub-PUD hugetlbfs unmaps on files without active PMD
sharing.  In that case, avoiding the unnecessary PUD-sized notifier
prevents KVM from zapping unrelated secondary mappings in the same PUD
range.

For workloads without secondary MMU mappings, without sub-PUD hugetlbfs
unmaps, or with active PMD sharing, the patch should mostly preserve the
existing behavior.

>
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -921,6 +921,9 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
>>   		simple_inode_init_ts(inode);
>>   		info->resv_map = resv_map;
>>   		info->seals = F_SEAL_SEAL;
>> +#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
>> +		info->pmd_sharing_seen = false;
>> +#endif
> This could use a slightly modified hugetlbfs_set_pmd_sharing_seen() and
> remove the ifdefs.
>
> 	hugetlbfs_set_pmd_sharing_seen(inode, false);


Thanks for pointing this out.  I will fix it in v3.

Thanks,
Zhe

>
> Not very important.