Re: [PATCH] Fix almost infinite loop in APIC

Marcelo Tosatti
2009-01-20T18:52:03Z

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