On Sun, 29 Apr 2012 15:59:18 +0300 Avi Kivity <avi@xxxxxxxxxx> wrote: > > As we discussed before, we need to add some tricks to de-couple mmu_lock and > > TLB flush. > > Ok, let's discuss them (we can apply the patch independently). Do you > have something in mind? > How about your own idea? http://www.spinics.net/lists/kvm/msg68550.html === > > How about something like a sequence lock: > > > > > > spin_lock(mmu_lock) > > need_flush = write_protect_stuff(); > > atomic_add(kvm->want_flush_counter, need_flush); > > spin_unlock(mmu_lock); > > > > while ((done = atomic_read(kvm->done_flush_counter)) < (want = > > atomic_read(kvm->want_flush_counter)) { > > kvm_make_request(flush) > > atomic_cmpxchg(kvm->done_flush_counter, done, want) > > } > > > > This (or maybe a corrected and optimized version) ensures that any > > need_flush cannot pass the while () barrier, no matter which thread > > encounters it first. However it violates the "do not invent new locking > > techniques" commandment. Can we map it to some existing method? > > There is no need to advance 'want' in the loop. So we could do > > /* must call with mmu_lock held */ > void kvm_mmu_defer_remote_flush(kvm, need_flush) > { > if (need_flush) > ++kvm->flush_counter.want; > } > > /* may call without mmu_lock */ > void kvm_mmu_commit_remote_flush(kvm) > { > want = ACCESS_ONCE(kvm->flush_counter.want) > while ((done = atomic_read(kvm->flush_counter.done) < want) { > kvm_make_request(flush) > atomic_cmpxchg(kvm->flush_counter.done, done, want) > } > } === Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
