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
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
