On 01/22/2012 06:32 AM, Paolo Bonzini wrote:
On 01/21/2012 09:39 PM, Jamie Lokier wrote:
Is this a timer that need to fire soon after setting, every time?
I wonder if a different kind of Windows timer, lower-resolution, could
be used if the timeout is longer. If it has insufficient resolution,
it could be set to trigger a little early, then set a high-resolution
timer at that point.
Maybe that could help for Linux CONFIG_NOHZ guests?
No, it's an implementation detail of Windows multimedia timers. Just
enabling them apparently burns CPU.
There is another kind of timers for Windows but it didn't work reliably.
Finding out why would be the right fix, but anyway
I'd looked into timer queues, which the developer docs suggested had
deprecated the use of mm timers, but I came across this which I figured
was why mm was preferred (%30 average error for a 50ms periodic/oneshot)
by the QEMU code:
http://www.virtualdub.org/blog/pivot/entry.php?id=272
Apparently Windows 7 has some fixes for drift that makes them reasonable
for a clock source, but still fairly low-res for an event timer.
I suppose we could use some historical timer data to adaptively
determine a reasonable minimum resolution to set...basically if the last
timer fired X ns ago, we'd configure the resolution to be 1/10th of that
periodic or whatever, and start them off low-res as James suggested to
avoid unnecessary CPU burn, but it's a pretty loose heuristic.
Reviewed-by: Paolo Bonzini <pbonz...@redhat.com>
Paolo
