On Tue, May 14, 2019 at 01:52:23PM +0200, Peter Zijlstra wrote:
On Mon, May 13, 2019 at 05:38:04PM +0100, Will Deacon wrote:
On Fri, May 10, 2019 at 07:26:54AM +0800, Yang Shi wrote:
diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c index 99740e1..469492d 100644 --- a/mm/mmu_gather.c +++ b/mm/mmu_gather.c @@ -245,14 +245,39 @@ void tlb_finish_mmu(struct mmu_gather *tlb, { /* * If there are parallel threads are doing PTE changes on same range
* under non-exclusive lock (e.g., mmap_sem read-side) but defer TLB* flush by batching, one thread may end up seeing inconsistent PTEs* and result in having stale TLB entries. So flush TLB forcefully* if we detect parallel PTE batching threads.** However, some syscalls, e.g. munmap(), may free page tables, this* needs force flush everything in the given range. Otherwise this* may result in having stale TLB entries for some architectures,* e.g. aarch64, that could specify flush what level TLB.- if (mm_tlb_flush_nested(tlb->mm) && !tlb->fullmm) {
/** Since we can't tell what we actually should have* flushed, flush everything in the given range.*/tlb->freed_tables = 1;tlb->cleared_ptes = 1;tlb->cleared_pmds = 1;tlb->cleared_puds = 1;tlb->cleared_p4ds = 1;/** Some architectures, e.g. ARM, that have range invalidation* and care about VM_EXEC for I-Cache invalidation, need force* vma_exec set.*/tlb->vma_exec = 1;/* Force vma_huge clear to guarantee safer flush */tlb->vma_huge = 0;tlb->start = start;tlb->end = end;Whilst I think this is correct, it would be interesting to see whether or not it's actually faster than just nuking the whole mm, as I mentioned before.
At least in terms of getting a short-term fix, I'd prefer the diff below if it's not measurably worse.
So what point? General paranoia? Either change should allow PPC to get rid of its magic mushrooms, the below would be a little bit easier for them because they already do full invalidate correct.
Right; a combination of paranoia (need to remember to update this code to "flush everything" if we add new fields to the gather structure) but I also expected the performance to be better on arm64, where having two CPUs spamming TLBI messages at the same time is likely to suck.
I'm super confused about the system time being reported as higher with this change. That's really not what I expected.
Will