Re: kvm guest loops_per_jiffy miscalibration under host load

[Jan Kiszka <jan.kiszka@siemens.com>]

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