Re: [Xen-ia64-devel] [PATCH] NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ is notregistered.

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Tue, Jan 30, 2007 at 09:46:04AM +0800, Xu, Anthony wrote:
> 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?

Because the counter is finite.
If we can ignore conter overflow, we can check only which counter
is bigger.
But when overflow comes in (i.e. counter == 0 after increment),
things become complicated. It's the reason of new_tlbflush_clock_period.

Probably another approach to address overflow is to use signed comparison
like Linux jiffies time_after().
But we can't assume the distance between two conters is near enough.


> > 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.

It does.
destroy_grant_host_mapping()
  => domain_page_flush_and_put()
     => domain_flush_vtalb_all()
        or
        domain_flush_vtlb_track_entry()
Yes, this execution path is somewhat confusing.
I think that flush_tlb_mask(current->domain->domain_dirty_cpumask)
should be replaced with something like arch_flush_tlb(current).

-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel