[patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault
Linus Torvalds
torvalds at linux-foundation.org
Wed Jul 29 05:02:08 AEST 2020
On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin <npiggin at gmail.com> wrote:
>
> The quirk is a problem with coprocessor where it's supposed to
> invalidate the translation after a fault but it doesn't, so we can get a
> read-only TLB stuck after something else does a RO->RW upgrade on the
> TLB. Something like that IIRC. Coprocessors have their own MMU which
> lives in the nest not the core, so you need a global TLB flush to
> invalidate that thing.
So I assumed, but it does seem confused.
Why? Because if there are stale translations on the co-processor,
there's no guarantee that one of the CPU's will have them and take a
fault.
So I'm not seeing why a core CPU doing spurious TLB invalidation would
follow from "stale TLB in the Nest".
If anything, I think "we have a coprocessor that needs to never have
stale TLB entries" would impact the _regular_ TLB invalidates (by
update_mmu_cache()) and perhaps make those more aggressive, exactly
because the coprocessor may not handle the fault as gracefully.
I dunno. I don't know the coprocessor side well enough to judge, I'm
just looking at it from a conceptual standpoint.
Linus
More information about the Linuxppc-dev
mailing list