On Sun, 2011-01-30 at 15:16 +0200, Avi Kivity wrote:
> On 01/28/2011 09:52 PM, Glauber Costa wrote:
> > Register steal time within KVM. Everytime we sample the steal time
> > information, we update a local variable that tells what was the
> > last time read. We then account the difference.
> >
> >
> >
> > static void kvm_guest_cpu_offline(void *dummy)
> > {
> > kvm_pv_disable_apf(NULL);
> > + native_write_msr(MSR_KVM_STEAL_TIME, 0, 0);
> > apf_task_wake_all();
> > }
>
> Don't use the native_ versions, they override the pvops implementation.
> It doesn't matter for kvm, but we're not supposed to know this.
fair.
> > + /*
> > + * using nanoseconds introduces noise, which accumulates easily
> > + * leading to big steal time values. We want, however, to keep the
> > + * interface nanosecond-based for future-proofness. The hypervisor may
> > + * adopt a similar strategy, but we can't rely on that.
> > + */
> > + delta /= NSEC_PER_MSEC;
> > + delta *= NSEC_PER_MSEC;
>
> You're working around this problem both in the guest and host. So even
> if we fix it in one, it will still be broken in the other.
And if you notice, in two different ways:
I am (was) forcing to usecs in the host, and msecs in the guest.
One of the problems here, is that if we account steal time, we refrain
from accounting user / system time. Reason being, that if we account it,
we'll end up with more than HZ ticks per HZ, since we'll account ticks
as both steal and real.
And since the granularity of the cpu accounting is too coarse, we end up
with much more steal time than we should, because things that are less
than 1 unity of cputime, are often rounded up to 1 unity of cputime.
Now, I've already said that I will investigate further, and I'm ready to
back of from all of this. But assuming my analysis is right so far, what
if we keep things in nsecs or msecs, and only convert to cputime in the
time of read? This would allow us to just subtract steal time from
user/system time, in a more fine grained way.
--
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
