Re: add back pending timer irqs for kernel APIC timer

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> 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.
>   

You're right -- if the host is overloaded, this will generate interrupts 
which cannot be handled in time.  So it makes sense to disable the 
hrtimer if we are preempted and if we are not in hlt sleep (e.g. 
involuntary preemption).

>   
>> 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. 
>   

So we need the hrtimer anyway.  Seems like it's only a win if the host 
is overloaded and the guests are running; an idle guest requires an hrtimer.

There is an alternative, if we have multiple vcpus set with the same 
frequency we can try to use one hrtimer per cpu for all of them.  This 
doesn't work for dyntick guests but should work if most guests are the 
same type.

>   
>>> 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.
>   

I think the hrtimer code deals with this, Linux has to deal with a lot 
of timers.

>   
>>> 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.
>   

We need to make sure we are solving the right problem... do you have any 
traces which show that timer handling is a performance issue?

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/