Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On Wed, Jul 12, 2017 at 4:27 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >> Actually, I think that based on Andy’s patches there is a relatively >> reasonable solution. For each mm we will hold both a “pending_tlb_gen” >> (increased under the PT-lock) and an “executed_tlb_gen”. Once >> flush_tlb_mm_range finishes flushing it will use cmpxchg to update the >> executed_tlb_gen to the pending_tlb_gen that was prior the flush (the >> cmpxchg will ensure the TLB gen only goes forward). Then, whenever >> pending_tlb_gen is different than executed_tlb_gen - a flush is needed. > > Why do we need executed_tlb_gen? We already have > cpu_tlbstate.ctxs[...].tlb_gen. Or is the idea that executed_tlb_gen > guarantees that all cpus in mm_cpumask are at least up to date to > executed_tlb_gen? Hm... So actually it may be enough, no? Just compare mm->context.tlb_gen with cpu_tlbstate.ctxs[...].tlb_gen and flush if they are different? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
