Re: Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 29.10.25 19:02, Lorenzo Stoakes wrote:
> On Wed, Oct 29, 2025 at 05:19:54PM +0100, David Hildenbrand wrote:
>>>>>> Why is a tlb_remove_table_sync_one() needed in huge_pmd_unshare()?
>>>>>
>>>>> Because nothing else on that path is guaranteed to send any IPIs
>>>>> before the page table becomes reusable in another process.
>>>>
>>>> I feel that David's suggestion of just disallowing the use of shared page
>>>> tables like this (I mean really does it actually come up that much?) is the
>>>> right one then.
>>>
>>> Yeah, I also like that suggestion.
>>
>> I started hacking on this (only found a bit of time this week), and in
>> essence, we'll be using the mmu_gather when unsharing to collect the pages
>> and handle the TLB flushing etc.
>>
>> (TLB flushing in that hugetlb area is a mess)
>>
>> It almost looks like a cleanup.
>>
>> Having that said, it will take a bit longer to finish it and, of course, I
>> first have to test it then to see if it even works.
>>
>> But it looks doable. :)
> 
> Ohhhh nice :)
> 
> I look forward to it!

As shared offline already, it looked simple, but there is one nasty 
corner case: if we never reuse a shared page table, who will take care 
of unmapping all pages?

I played with various ideas, but it just ended up looking more 
complicated and possibly even slower.

So what I am currently looking into is simply reducing (batching) the 
number of IPIs.

In essence, we only have to send one IPI when unsharing multiple page 
tables, and we only have to send one when we are the last one sharing 
the page table (before it can get reused).

While at it, I'm looking into making also the TLB flushing easier to 
understand here.

I'm hacking on a prototype and should likely have something to test this 
week.

[I guess what I am doing now is aligned with Jann's initial ideas to 
optimize this ]

-- 
Cheers

David