On 03/11/2010 10:42 AM, Gleb Natapov wrote:
On Thu, Mar 11, 2010 at 04:38:48PM +0800, Sheng Yang wrote:
On Thursday 11 March 2010 16:31:57 Gleb Natapov wrote:
On Thu, Mar 11, 2010 at 10:28:12AM +0200, Avi Kivity wrote:
On 03/11/2010 10:23 AM, Sheng Yang wrote:
I have kept --no-hpet in my setup for
months...
Any details about the problems? HPET is important to some guests.
Seems like HPET reaction is too slow to satisfy some guests(for it would
replace PIT).
Here is the thread last time.
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/44899
Thanks. We can address this in three ways: first, adjust the guest
not to do timing related tests when virtualized (since no matter
what we do, the tests may fail). Second, I think we should
implement userspace ack notifiers (similar to tpr access notifiers
already present). Third, we can implement a kernel hpet, which,
after we solve the zillion bug it introduces, will also give a nice
performance improvement for hpet intensive workloads.
Second will not solve the problem. Presence of ack notifiers will not
make HPET interrupt arrive faster.
The slow may also due to lost tick. And with the lost tick, hpet is still
unusable...
If the problem it due to lost ticks reinjection may solve it, but only partially.
What if IO thread haven't run even once during the time vcpu did clock
source check? IIRC sometimes we trigger this even with in kernel PIT.
That is true. Reinjection can correct problems in the long term, but
may fail in the short term. 10 ticks is easily short term in a heavily
loaded system.
How does it happen with kernel PIT? I could understand it if we had a
work item doing the injection, but everything happens either from
hrtimer context or vcpu context.
--
error compiling committee.c: too many arguments to function
--
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
