qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fabrice Bellard
Subject: Re: [Qemu-devel] [PATCH] Timer/clock for Linux
Date: Tue, 25 Apr 2006 23:10:51 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]