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@xxxxxxxxxxxxxxx/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? BTW, a massive amount of hrtimers (_single_ non-tickless 32-vcpu guest with LAPIC) results in: hrtimer: interrupt took 122448 ns in the host. So don't even need impossibly small timeouts :( -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
