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

[Zachary Amsden <zamsden@redhat.com>]

On 06/09/2010 11:24 PM, Avi Kivity wrote:
> On 06/10/2010 12:17 AM, 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...
>>
>
> Restarting on ack has the big advantage of not rearming at all if the 
> guest doesn't ack, i.e. a timer left running talking to a masked irq pin.
>

Exactly... it scales too, with how fast we can manage to deliver the 
interrupts.  We just have to be sure we don't drop the re-fire 
completely in any race conditions.  Some stress will be required.

Zach