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.
-- error compiling committee.c: too many arguments to function -- 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
