On 02/16/2012 06:50 AM, Xiao Guangrong wrote: > I think we do not need handle all tlb-flushed request here since all of these > request can be delayed to the point where mmu-lock is released , we can simply > do it: > > void kvm_mmu_defer_remote_flush(kvm, need_flush) > { > if (need_flush) > ++kvm->tlbs_dirty; > } > > void kvm_mmu_commit_remote_flush(struct kvm *kvm) > { > int dirty_count = kvm->tlbs_dirty; > > smp_mb(); > > if (!dirty_count) > return; > > if (make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.remote_tlb_flush; <-- point A > cmpxchg(&kvm->tlbs_dirty, dirty_count, 0); > } > > if this is ok, we only need do small change in the current code, since > kvm_mmu_commit_remote_flush is very similar with kvm_flush_remote_tlbs(). Suppose at point A another thread executes defer_remote_flush(), commit_remote_flush(), and defer_remote_flush() again. This brings the balue of tlbs_dirty back to 1 again, with the tlbs dirty. The cmpxchg() then resets tlbs_dirty, leaving the actual tlbs dirty. -- error compiling committee.c: too many arguments to function -- 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