Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Gleb Natapov]

On Mon, Feb 07, 2011 at 03:46:54PM +0200, Avi Kivity wrote:
> On 02/07/2011 03:41 PM, Gleb Natapov wrote:
> >On Mon, Feb 07, 2011 at 07:23:22AM -0600, Anthony Liguori wrote:
> >>  On 02/07/2011 07:14 AM, Avi Kivity wrote:
> >>  >On 02/07/2011 03:11 PM, Anthony Liguori wrote:
> >>  >>On 02/07/2011 06:34 AM, Avi Kivity wrote:
> >>  >>>On 02/04/2011 10:56 AM, Jan Kiszka wrote:
> >>  >>>>>
> >>  >>>>>   This should be a rare event.  If you are missing 50% of your
> >>  >>>>>   notifications, not amount of gradual catchup is going to
> >>  >>>>help you out.
> >>  >>>>
> >>  >>>>But that's the only thing this patch is after: lost ticks at
> >>  >>>>QEMU level.
> >>  >>>
> >>  >>>Most lost ticks will happen at the vcpu level.  The iothread
> >>  >>>has low utilization and will therefore be scheduled promptly,
> >>  >>>whereas the vcpu thread may have high utilization and will
> >>  >>>thus be preempted.  When it is preempted for longer than the
> >>  >>>timer tick, we will see vcpu-level coalescing.  All it takes
> >>  >>>is 2:1 overcommit to see time go half as fast; I don't think
> >>  >>>you'll ever see that on bare metal.
> >>  >>
> >>  >>But that's not to say that doing something about lost ticks in
> >>  >>QEMU isn't still useful.
> >>  >>
> >>  >
> >>  >If it doesn't solve the majority of the problems it isn't very
> >>  >useful IMO.  It's a good first step, but not sufficient for real
> >>  >world use with overcommit.
> >>
> >>  Even if we have a way to detect coalescing, we still need to make
> >>  sure we don't lose ticks in QEMU.  So regardless of whether it
> >>  solves the majority of problems, we need this anyway.
> >>
> >Actually it is very strange we lose them. Last time I checked vm_clock
> >worked in such a way that if ticks were lost due to qemu not been scheduled
> >for a long time timer callback was repeatedly fired to compensate for
> >missed wakeups.
> >
> 
> That's quite pointless, since those interrupts will be coalesced by
> the guest.
> 
Yes, of course, and this is what I remember happening. At this point
interrupt de-coalescing kicks in.

--
                        Gleb.