Hello. I''m looking over the Xen hpet.c to see what I can steal for the qemu implementation I''m working on. (Thank you kindly :-) One thing that doesn''t make sense to me is why, in hpet_timer_fn, the timer is set with: set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, period)); rather than calculating the difference between the final value of the comparator (after the time_after loop) and the current time. This is the approach used in hpet_set_timer: set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, diff)); and would seem to be the best way to get as close to the desired expire time as possible. Can someone explain why the approaches are different in these 2 places? -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I might use ''hg anno'' to see if anyone changed it to period for good reason, but it seems to me that your suggested approach would be more accurate, especially in the long run. -- Keir On 15/8/08 19:41, "Beth Kon" <eak@us.ibm.com> wrote:> Hello. I''m looking over the Xen hpet.c to see what I can steal for the > qemu implementation I''m working on. (Thank you kindly :-) > > One thing that doesn''t make sense to me is why, in hpet_timer_fn, the > timer is set with: > > set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, period)); > > rather than calculating the difference between the final value of the > comparator (after the time_after loop) and the current time. This is the > approach used in hpet_set_timer: > > set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, diff)); > > and would seem to be the best way to get as close to the desired expire > time as possible. Can someone explain why the approaches are different > in these 2 places?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel Magenheimer
2008-Aug-18 02:59 UTC
RE: [Xen-devel] Question about hpet calls to set_timer
On some Linux time algorithms, if hpet ticks are delivered too closely together, time advances too rapidly, whereas if they are late (delivered too far apart), the algorithm makes adjustments and time is kept properly. Dave Winchell is the expert in this area and had a patch for better hpet vpt handling submitted in early June but Keir requested some rework and it got delayed until after 3.3.0. Hopefully Dave can both comment on your questions and submit the reworked patch soon.> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Sunday, August 17, 2008 4:25 AM > To: Beth Kon; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Question about hpet calls to set_timer > > > I might use ''hg anno'' to see if anyone changed it to period > for good reason, > but it seems to me that your suggested approach would be more > accurate, > especially in the long run. > > -- Keir > > On 15/8/08 19:41, "Beth Kon" <eak@us.ibm.com> wrote: > > > Hello. I''m looking over the Xen hpet.c to see what I can > steal for the > > qemu implementation I''m working on. (Thank you kindly :-) > > > > One thing that doesn''t make sense to me is why, in > hpet_timer_fn, the > > timer is set with: > > > > set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, period)); > > > > rather than calculating the difference between the final > value of the > > comparator (after the time_after loop) and the current > time. This is the > > approach used in hpet_set_timer: > > > > set_timer(&h->timers[tn], NOW() + hpet_tick_to_ns(h, diff)); > > > > and would seem to be the best way to get as close to the > desired expire > > time as possible. Can someone explain why the approaches > are different > > in these 2 places? > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel