Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Fabrice Bellard <fabrice@bellard.org>]

Jamie Lokier wrote:
> Fabrice Bellard wrote:
> 
>>Can other people confirm that it is better to always use /dev/rtc on 
>>Linux ? Is there a way to get the real resolution of the host timer ?
> 
> 
> Yes, on recent Linux kernels you can do
> clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will
> return the length of a timer tick.  On my kernel it's 4.00025 ms.  On
> other x86 kernels it can be ~10ms or ~1ms.
> 
> Also the recent Linux kernels (more recent) offer "high-resolution
> timers"; you can guess what that means.  They should be more accurate
> than /dev/rtc when they're available, because they reprogram the timer
> chip, though I have never tried them.  I'd guess that kernels
> featuring them would return a small value from clock_getres().

Using clock_getres() seems a good idea if I can test that it is 
supported. If it is not supported then /dev/rtc will be used in any case.

> It's unfortunate that even on kernels where the kernel tick time is
> 1ms, setitimer() will cost you a 2ms delay.  But: why should that make
> Windows run slower?  Doesn't qemu read the kernel clock to determine
> that the guest is due approx. 2 timer interrupts for each host wakeup?
> Naturally you can't let that count increase indefinitely, if the
> emulator is too slow to run the guest at full speed, but it might be
> an idea to count up to a small number, so that short pauses in host
> kernel scheduling won't cause a guest to lose time.

QEMU reads the clock at each host wakeup, but it cannot compensate if 
the guest OS requires a higher frequency than the host timer frequency. 
Having a 1 ms period is definitively better to be able to run a wide 
range of guest OSes.

Fabrice.