Re: add back pending timer irqs for kernel APIC timer

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

Dong, Eddie wrote:
>> Note that my old lapic branch did a similar "tdf" thing as well and it
>> worked quite nicely, so I think Eddie is on the right track with
>> adding this.
>>     
>
> I just copied the whole APIC timer stuff from your old patch at that
> time as TODO. maybe I missed something :-(
>
> Time virtualization has quit a long way to go and it is quit very
> beginning now. Something in my plan:
>
> 1: Current 3 patches to fix the pending irq issues and accumulate issue.
>
> 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?

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.

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

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

> Will u be able to help together?
> thx,eddie
>   


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