On Fri, Nov 21, 2008 at 02:39:22PM -0200, Eduardo Habkost wrote: > On Fri, Nov 21, 2008 at 04:41:00PM +0100, Jan Kiszka wrote: > > Eduardo Habkost wrote: <snip> > > > I am seeing the problem here > > > when using the in-kernel PIT, but (surprisingly) my setup works when > > > using -no-kvm-pit. > > > > Weird, makes no sense to me as well ATM. > > The qemu PIT seems to calculate the timeout for its timer as a function > of the time where the PIT timer was set up (count_load_time) and the > last timer set up (next_transition_time), without looking at the current > time. After missing some ticks and getting the timer triggered late, > it will set up a lot of "trigger on the past" timers before the guest > finished the mdelay() loop. > > The in-kernel PIT seems to try to do the same thing (it just calls > hrtimer_add_expires_ns() on the timer), but maybe the behaviour of the > kernel timers is different of the qemu timers when a timer is set up > to be triggered on the past. On my host-HZ=250 guest-HZ=1000 setup, > it was incrementing pit_timer.pending only once every 4 milliseconds.
That's the case. From a probe on __pit_timer_fn.return: 19344471136382 timer_fn returning. timer expires now at: 19343448496177 19344475128359 timer_fn returning. timer expires now at: 19343449496025 19344479128694 timer_fn returning. timer expires now at: 19343450495873 19344483129394 timer_fn returning. timer expires now at: 19343451495721 The number at the beginning of the lines is ktime_get(). The timer expiration time is on the past, but the kernel keeps triggering the timer once every 4 ms. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
