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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Tue, Nov 18, 2025 at 11:03:07AM +0100, David Hildenbrand (Red Hat) wrote:
> 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?

Right. That is nasty... :)

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

Yeah...

>
> 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?

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?

>
> 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).

Right, hopefully that significantly cuts down on the amount genrated.

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

Good idea ;)

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

Thanks!

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

Cheers, Lorenzo