[PATCH -v2 2/2] arm64, tlbflush: don't TLBI broadcast if page reused in write fault

Barry Song 21cnbao at gmail.com
Wed Oct 22 03:52:23 PDT 2025


On Wed, Oct 22, 2025 at 11:34 PM Huang, Ying
<ying.huang at linux.alibaba.com> wrote:
>
> Barry Song <21cnbao at gmail.com> writes:
>
> > On Wed, Oct 22, 2025 at 10:46 PM Huang, Ying
> > <ying.huang at linux.alibaba.com> wrote:
> >
> >> >
> >> > I agree. Yet the ish barrier can still avoid the page faults during CPU0's PTL.
> >>
> >> IIUC, you think that dsb(ish) compared with dsb(nsh) can accelerate
> >> memory writing (visible to other CPUs).  TBH, I suspect that this is the
> >> case.
> >
> > Why? In any case, nsh is not a smp domain.
>
> I think dsb(ish) will be slower than dsb(nsh) in theory.  I guess that
> dsb just wait for the memory write to be visible in the specified
> shareability domain instead of making write faster.
>
> > I believe a dmb(ishst) is sufficient to ensure that the new PTE writes
> > are visible
>
> dmb(ishst) (smp_wmb()) should pair with dmb(ishld) (smp_rmb()).
>
> > to other CPUs. I’m not quite sure why the current flush code uses dsb(ish);
> > it seems like overkill.
>
> dsb(ish) here is used for tlbi(XXis) broadcast.  It waits until the page
> table change is visible to the page table walker of the remote CPU.

It seems we’re aligned on all points[1], although I’m not sure whether
you have data comparing A and B.

A:
write pte
don't broadcast pte
tlbi
don't broadcast tlbi

with

B:
write pte
broadcast pte
tlbi
don't broadcast tlbi

I guess the gain comes from "don't broadcat tlbi" ?
With B, we should be able to share many existing code.

[1] https://lore.kernel.org/linux-mm/20251013092038.6963-1-ying.huang@linux.alibaba.com/T/#m54312d4914c69aa550bee7df36711c03a4280c52

Thanks
Barry



More information about the linux-arm-kernel mailing list