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

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

On 11/19/25 17:31, David Hildenbrand (Red Hat) wrote:
> On 19.11.25 17:29, David Hildenbrand (Red Hat) wrote:
>>>>
>>>> So what I am currently looking into is simply reducing (batching) the number
>>>> of IPIs.
>>>
>>> As in the IPIs we are now generating in tlb_remove_table_sync_one()?
>>>
>>> Or something else?
>>
>> Yes, for now. I'm essentially reducing the number of
>> tlb_remove_table_sync_one() calls.
>>
>>>
>>> As this bug is only an issue when we don't use IPIs for pgtable freeing right
>>> (e.g. CONFIG_MMU_GATHER_RCU_TABLE_FREE is set), as otherwise
>>> tlb_remove_table_sync_one() is a no-op?
>>
>> Right. But it's still confusing: I think for page table unsharing we
>> always need an IPI one way or the other to make sure GUP-fast was called.
>>
>> At least for preventing that anybody would be able to reuse the page
>> table in the meantime.
>>
>> That is either:
>>
>> (a) The TLB shootdown implied an IPI
>>
>> (b) We manually send one
>>
>> But that's where it gets confusing: nowadays x86 also selects
>> MMU_GATHER_RCU_TABLE_FREE, meaning we would get a double IPI?
>>
>> This is so complicated, so I might be missing something.
>>
>> But it's the same behavior we have in collapse_huge_page() where we first
> 
> ... flush and then call tlb_remove_table_sync_one().
> 

Okay, I pushed something to

https://github.com/davidhildenbrand/linux.git hugetlb_unshare

I did a quick test and my house did not burn down. But I don't have a 
beefy machine to really stress+benchmark PMD table unsharing.

Could one of the original reporters (Stanislav? Prakash?) try it out to 
see if that would help fix the regression or if it would be a dead end?

-- 
Cheers

David