Re: add back pending timer irqs for kernel APIC timer

Dong, Eddie
2007-08-13T14:50:22Z

Avi Kivity wrote:
>> 2: stop hrtimer when the guest is descheduled to increase
>> scalibility and remove apic->lock.
>>
>
> Why is this important? An hrtimer is just an entry on a list, no?

Does it need an IRQ to drive? If we have ten VMs, we got extra 10 IRQs.

>
> Do you mean, just if the guest is preempted (not during hlt)?
> Is it so
> important? We're talking a few thousand wakeups per second.

The majority of wakeup is APIC timer in normal SMP case.
This is important for deep C state power management. If guest is 1KHZ,
we may get 10KHZ IRQs if 10 VMs are running.

If it is in HLT, we need to set up an hrtimer or similar to wakeup the
HLT.

>
>> 3: Use scale + shift like Xen did to make sure no internal overflow
>> if we run guest contiguously for long time say 2 years.
>>
>
> hrtimers are in 64-bit nanoseconds. That gives about 160 years.
>

I assume TSC is better than hrtimer, see next bullet. When we convert
from TSC to PIT timer, a multiply is a must and we need to carefully
design
the scale and factor to not overflow if we stick in 64bits ops.

Notes here: We may not want to use 64bits * 64bits = 128bits as it is
too expansive. (?)
This is What Xen did and have some sense if we pay attention to
performance very much.

>> Above 1-3 is already in Xen and we just need to port.
>>
>>
>> 4: Should we use hrtimer? How efficieny it is?
>>
>>
>>
>
> Sure, hrtimer is the future.

Maybe I am wrong, but the point is that we don't care about accuracy
since
we only need an IRQ to interrupt guest at around the guest fire time.
(A host timer IRQ triggered VM Exit and many callbacks in host which
should
exceeds 5K cycles) We can simply use TSC (much efficient IMO) and
present guest APIC
freqeuncy = host TSC frequency. This way we don't need to do
muliple/dividen etc. Anyway it depends on if we can find an much
efficient timer:-)
I have no idea here.

Eddie