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

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

Isaku Yamahata write on 2007年1月30日 11:36:
> 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.
> 
> 
Understand now.
One more question

Why need local_vhpt_flush and vcpu_vhpt_flush call 
tlbflush_clock_inc_and_return?

In per-CPU VHPT mode,
tlbflush_clock_inc_and_return only needs to be called in local_flush_tlb_all.

Am I right?

Thanks,
Anthony

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