From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: kvm guest loops_per_jiffy miscalibration under host load Date: Tue, 22 Jul 2008 09:49:29 -0300 Message-ID: <20080722124929.GA24724@dmt.cnet> References: <20080722032510.GB1358@dmt.cnet> <488598A8.8040104@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "David S. Ahern" , Glauber Costa , kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([66.187.233.31]:44070 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752022AbYGVMu0 (ORCPT ); Tue, 22 Jul 2008 08:50:26 -0400 Content-Disposition: inline In-Reply-To: <488598A8.8040104@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jul 22, 2008 at 10:22:00AM +0200, Jan Kiszka wrote: > > The in-kernel PIT rearms relative to host clock, so the frequency is > > more reliable (next_expiration = prev_expiration + count). > > The same happens under plain QEMU: > > static void pit_irq_timer_update(PITChannelState *s, int64_t current_time); > > static void pit_irq_timer(void *opaque) > { > PITChannelState *s = opaque; > > pit_irq_timer_update(s, s->next_transition_time); > } True. I misread "current_time". > To my experience QEMU's PIT is suffering from lost ticks under load > (when some delay gets larger than 2*period). Yes, with clock=pit on RHEL4 its quite noticeable. Even with -tdf. The in-kernel timer seems immune to that under the load I was testing. > I recently played a bit with QEMU new icount feature. Than one tracks > the guest progress based on a virtual instruction pointer, derives the > QEMU's virtual clock from it, but also tries to keep that clock in sync > with the host by periodically adjusting its scaling factor (kind of > virtual CPU frequency tuning to keep the TSC in sync with real time). > Works quite nicely, but my feeling is that the adjustment is not 100% > stable yet. > > Maybe such pattern could be applied on kvm as well with tsc_vmexit - > tsc_vmentry serving as "guest progress counter" (instead of icount which > depends on QEMU's code translator). I see. Do you have patches around?