Re: [RFC][PATCH 1/3] Introduce a workqueue to deliver PIT timer interrupts.

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Jun 09, 2010 at 11:17:41AM -1000, Zachary Amsden wrote:
> 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@vger.kernel.org/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?

8