[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] [PATCH] NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is notregistered.
Isaku Yamahata write on 2007年1月29日 18:29: > > How about the following example? > For simplicity, we consider only local_flush_tlb_all(). > (The similar argument can be applied to vcpu_vhpt_flush()) > > suppose domM has two vcpus, vcpu0, vcpu1. > domN has one vcpu, vcpu2. > > - case 1 > vcpu0 and vcpu1 are running on same pcpu. > vcpu0 runs. > context switch <<<< local_flush_tlb_all() is necessry here > vcpu1 runs. > > - case 2 > vcpu0, vcpu1 and vcpu2 are running on the same pcpu > vcpu0 runs > context switch > vcpu2 runs > vcpu2 issues local_tlb_flush(). > context switch <<< local_flush_tlb_all() can be skipped. I can understand this. Yes, this local_flush_tlb_all can be skipped, But it is because vcpu2 issues local_tlb_flush. My question is why we need new_tlbflush_clock_period? > vcpu1 runs > > You can confirm its effect by the perf-counters, > tlbflush_clock_cswitch_skip, flush_vtlb_for_context_switch and > tlbflush_clock_cswitch_purge. > Please note that local_flush_tlb_all() (or vcpu_vhpt_flush()) is > called everytime grant table unmapping without tlb insert tracking Currently, grant table unmapping did not purge any thing, Because in flush_tlb_mask(current->domain->domain_dirty_cpumask); Domain_dirty_cpumask is always 0. Thanks, Anthony > optimization. But they aren't so often called with tlb insert > tracking optimization, tlb flush clock optimization becomes less > effetive than before. _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |