Re: [PATCH] Fix almost infinite loop in APIC

[Marcelo Tosatti <mtosatti@redhat.com>]

Hi Sheng,

On Tue, Jan 20, 2009 at 09:43:15PM +0800, Sheng Yang wrote:
> Marcelo, I realize some interesting things.
> 
> In fact, on my machine, when I measured the delta of now() and last_update at 
> kvm_apic_timer_intr_post(), the delta was bigger and bigger...(and now() is 
> always bigger for me, so still no clue for why data can be like above, 
> last_update always ahead of when for about one period...).
> 
> Then I found something not good in original design - it ignored the interval 
> between time fire and injection, so we got:
> 
> last_update = now() + n * period;
> 
> And the time we update last_update:
> 
> time = now() + n * period + n * interval.
> 
> So last_update time is more and more inaccurate... Though it was revised by 
> tmcct function, it's still not a good way to go.
> 
> Then I understand your purpose more.
> 
> +       if (unlikely(atomic_read(&apic->timer.pending) > 0)) {
> +               remaining = apic->timer.injection_delay;
> +               if (ktime_to_ns(remaining) > apic->timer.period)
> +                       remaining = ns_to_ktime(apic->timer.period);
> +        } else
> +               remaining = hrtimer_expires_remaining(&apic->timer.dev);
> 
> And about your patch, how about take interval between intr_post() and read 
> tmcct in to account as well? 

You mean to sum up interval between intr_post() and read tmcct into
injection_delay? 

I don't get it. Can you be more descriptive please?

> That can keep the consistent with hrtimer_get_remaining() in the read 
> tmcct.

> And I think if remaining > period, 
> remaining = remain % period maybe more reasonable here.

Yes, thats better.

> How do you think?
> 
> -- 
> regards
> Yang, Sheng
> 
>