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

[Zachary Amsden <zamsden@redhat.com>]

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?