From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: kvm guest loops_per_jiffy miscalibration under host load Date: Tue, 22 Jul 2008 17:54:50 +0200 Message-ID: <488602CA.509@siemens.com> References: <20080722032510.GB1358@dmt.cnet> <488598A8.8040104@siemens.com> <20080722124929.GA24724@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "David S. Ahern" , Glauber Costa , kvm-devel To: Marcelo Tosatti Return-path: Received: from gecko.sbs.de ([194.138.37.40]:21542 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbYGVPzf (ORCPT ); Tue, 22 Jul 2008 11:55:35 -0400 In-Reply-To: <20080722124929.GA24724@dmt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: > 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? Unfortunately, not. It's so far just a vague idea how it /may/ work - I'm lacking time to study or even implement details ATM. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux