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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
