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.