>>> Yes, good thinking, but this should only be done if it actually >impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if >it >>> introduces extra complexity. >>> >> >> >> If the overhead is that small, why are we touching this code in the >first >> place? >> > >Accuracy is much more important from my point of view. Also, the >reduction in the number of signals delivered when the guest uses 100Hz >is significant. >
Actually the main motivation for dyn-tick in qemu was to enable smooth fix of time drift problem in the guests. On kernels without dyn-tick enabled sigalarm didn't reach qemu on accurate times, thus caused convergence of several pit irqs into one. Currently we use a time-drift-fix written by Uri Lublin which counts the number of irq acked by the guest and tries to inject another one immidietly until the drift is fixed. This worked fine but caused jumps for multimedia applications. We wanted a way to smooth it by increasing the rate of pit timer in case of drift to a frequency higher than 1000HZ until the drift is fixed. Dan K. tries to test application behviour with it. -- Dor. ------------------------------------------------------------------------- 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
