On 06/09/2010 03:23 AM, Marcelo Tosatti wrote:
On Tue, Jun 08, 2010 at 04:36:16PM -1000, Zachary Amsden wrote:
+ pt->timer.function = pit_timer_fn;
I am happy to see this. I thought kvm_timer_fn was a step
backwards; it was too general of a function to justify the savings
of 20 some odd lines of code.
This was not done to save 20 lines of code:
http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg18640.html
Is there any chance that using a workqueue might help the problem of
hrtimers firing too quickly? I wanted to return HR_NORESTART from
pit_timer_fn always, then restart the hrtimer on delivery, but
because of unreliable delivery, it wasn't clear how to do that.
Perhaps the workqueue can be used to restart the timer instead,
avoiding problems of impossibly small timeouts causing hrtimers to
run amok.
It should be rearmed on ACK ideally. How come delivery is unreliable?
Due to the various ways IRQ can be latched or not with different
routing. If you program a very short timeout, it should fire even if
the guest is slow to respond:
i..i..i..i..i..i..i
..a...a...a...a
if you don't restart right away, only on ack, you can risk the refire of
the interrupt getting lost, especially if the guest happens to reprogram
the PIT while this is happening...
Of course, it can be tracked properly, but it requires quite a few more
state variables and some careful reasoning to make sure it doesn't drop
irqs.
This patch series looks as if it will make that sort of reasoning easier
to do :)
BTW, a massive amount of hrtimers (_single_ non-tickless 32-vcpu guest
with LAPIC) results in:
hrtimer: interrupt took 122448 ns
in the host. So don't even need impossibly small timeouts :(
32-vcpu on how many pcpu?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
