Re: [PATCH] mm/hugetlb: fix overbroad MMU notifiers for unshared PMDs

[Li Zhe]

On 9/1/26 8:32 AM, Andrew Morton wrote:
> On Mon, 31 Aug 2026 17:10:23 +0800 "Li Zhe" <lizhe.67@xxxxxxxxxxxxx> 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 MADV_DONTNEED, a shared mapping can pass
>> the "PMD sharing is possible" range test in function
>> adjust_range_if_pmd_sharing_possible() even when the PMD table covering
>> the target 2M page is not shared. KVM then receives a 1G invalidation for
>> a 2M operation and zaps unrelated secondary mappings, so the guest has to
>> fault them back in.
>>
>> Fix this by using the existing cheap "sharing possible" test only as a
>> gate, then inspect the candidate PMD tables under the locks held by the
>> hugetlb unmap paths. The notifier is expanded only for PUDs whose PMD
>> table is actually shared, while the other callers keep the existing
>> conservative expansion.
> Thanks.
>
>> 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%.
> So a modest performance improvement?

Yes, I would describe the measured end-to-end improvement as modest and
workload-specific. The Redis number is mainly intended to show that the
over-notification can have a visible impact in a real workload; it is not
meant to be a general benchmark result.

>
> This led Sashiko to perhaps discover what it considers a "critical"
> pre-existing bug.
>
> 	https://sashiko.dev/#/patchset/20260831091023.66581-1-lizhe.67@xxxxxxxxxxxxx
Regarding the Sashiko report, it looks like a valid pre-existing issue to
me. I have not yet looked into it in full detail, but I will spend more
time analyzing the problem and the proper fix. If that analysis confirms
the issue, I plan to send a separate fix patch for it.

Thanks,
Zhe