Thread (70 messages) 70 messages, 5 authors, 2017-07-27

Re: Potential race in TLB flush batching?

From: Nadav Amit <hidden>
Date: 2017-07-12 23:42:34

Andy Lutomirski [off-list ref] wrote:
On Wed, Jul 12, 2017 at 4:27 PM, Nadav Amit [off-list ref] wrote:
quoted
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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help