Re: [PATCH v1 1/1] mm/khugepaged: move tlb_remove_table_sync_one out from under PTL

[Lance Yang]

On 2026/1/16 09:03, Baolin Wang wrote:
> On 1/15/26 8:28 PM, Lance Yang wrote:
> > On 2026/1/15 18:00, Baolin Wang wrote:
> > > Hi Lance,
> > >
> > > On 1/15/26 3:16 PM, Lance Yang wrote:
> > > > From: Lance Yang <lance.yang@xxxxxxxxx>
> > > >
> > > > tlb_remove_table_sync_one() sends IPIs to all CPUs and waits for them,
> > > > which we really don't want to do while holding PTL.
> > >
> > > Could you add more comments to explain why this is safe for the PAE 
> > > case?
> >
> > Yep, IIUC, it is safe because we've already done pmdp_collapse_flush()
> > which ensures the PMD change is visible.
> >
> > pmdp_get_lockless_sync() (which calls tlb_remove_table_sync_one() on PAE)
> > is just to ensure any ongoing lockless pmd readers (e.g., GUP-fast) 
> > complete
> > before we proceed. It sends IPIs to all CPUs and waits for responses - 
> > a CPU
> > can only respond when it's not between local_irq_save() and 
> > local_irq_restore().
> >
> > Moving it out from under PTL doesn't change the synchronization 
> > semantics,
> > since lockless readers don't depend on PTL anyway.
>
> Cc Hugh who introduced the pmdp_get_lockless_sync(), to double check.
>
> Sounds reasonable to me, please add these comments into the commit 
> message. Thanks.

Yes, will do. Thanks!

> > > For the non-PAE case, you added a new tlb_remove_table_sync_one(), 
> > > why we need this (to solve what problem)? Please also add more 
> > > comments to explain.
> >
> > Oops, you're right, the original macro was a no-op for non-PAE.
> >
> > I should just move the macro call out from under PTL, rather than
> > replacing it with direct tlb_remove_table_sync_one() calls.
>
> OK.

Cheers,
Lance