On Wed, Jul 18, 2018 at 11:33:02AM -0400, Rik van Riel wrote: > The tlb flush code first increments mm->context.tlb_gen, and then sends > shootdown IPIs to CPUs that have this mm loaded and are not in lazy > TLB mode. > > At context switch time, we have to ensure that we check the tlb_gen after > we load the old is_lazy state. > > Maybe something like this? > > /* > * Read the tlb_gen to check whether a flush is needed. > * If the TLB is up to date, just use it. > * The TLB shootdown code first increments tlb_gen, and then > * sends IPIs to CPUs that have this CPU loaded and are not > * in lazy TLB mode. The barrier ensures we handle > * cpu_tlbstate.is_lazy before tlb_gen, keeping this code > * synchronized with the TLB flush code. > */ Let me try and draw a diagram; that always works better for me that text. So the relevant ordering is something like: CPU0 - switch_mm() CPU1 - flush_tlb_mm_range() [W] cpu_tlbstate.is_lazy = false; [RmW] next->tlb_gen++ smp_mb() MB (implied) [R] tlb_gen = next->tlb_gen native_flush_tlb_others() [R] cpu_tlbstate.is_lazy Such that CPU1 either observes !lazy and flushes and/or CPU0 observes the generation increment and forces a flush itself. Either way, CPU0 gets flushed. Also, I don't suppose you've looked at the paravirt instances of flush_tlb_other() ? They don't elide the flushes because of lazy. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|