From: Glauber Costa <glommer@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
aliguori@us.ibm.com, Rik van Riel <riel@redhat.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 4/6] KVM-GST: KVM Steal time registration
Date: Tue, 01 Feb 2011 13:53:38 -0200 [thread overview]
Message-ID: <1296575618.5081.13.camel@mothafucka.localdomain> (raw)
In-Reply-To: <4D45649A.4090709@redhat.com>
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.
next prev parent reply other threads:[~2011-02-01 15:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-28 19:52 [PATCH v2 0/6] KVM Steal time, new submission Glauber Costa
2011-01-28 19:52 ` [PATCH v2 1/6] KVM-HDR: KVM Steal time implementation Glauber Costa
2011-01-29 1:28 ` Rik van Riel
2011-01-28 19:52 ` [PATCH v2 2/6] KVM-HV: " Glauber Costa
2011-01-29 1:46 ` Rik van Riel
2011-01-30 13:13 ` Avi Kivity
2011-02-01 15:48 ` Glauber Costa
2011-02-01 17:09 ` Avi Kivity
2011-02-01 19:58 ` Glauber Costa
2011-02-02 10:09 ` Avi Kivity
2011-01-31 11:07 ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 3/6] KVM-GST: KVM Steal time accounting Glauber Costa
2011-01-29 1:16 ` Jeremy Fitzhardinge
2011-01-29 1:27 ` Glauber Costa
2011-01-29 1:53 ` Rik van Riel
2011-01-30 14:04 ` Avi Kivity
2011-01-30 16:45 ` lidong chen
2011-02-01 15:58 ` Glauber Costa
2011-02-01 15:57 ` Glauber Costa
2011-02-02 10:11 ` Avi Kivity
2011-02-02 10:51 ` Avi Kivity
2011-02-02 11:57 ` Glauber Costa
2011-01-28 19:52 ` [PATCH v2 4/6] KVM-GST: KVM Steal time registration Glauber Costa
2011-01-29 2:16 ` Rik van Riel
2011-01-30 13:16 ` Avi Kivity
2011-02-01 15:53 ` Glauber Costa [this message]
2011-02-01 16:17 ` Peter Zijlstra
2011-02-01 17:00 ` Glauber Costa
2011-02-01 17:44 ` Peter Zijlstra
2011-02-01 20:20 ` Venkatesh Pallipadi
2011-01-31 11:11 ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 5/6] KVM-GST: adjust scheduler cpu power Glauber Costa
2011-01-31 11:25 ` Peter Zijlstra
2011-01-31 11:27 ` Peter Zijlstra
2011-02-01 15:59 ` Glauber Costa
2011-02-01 16:19 ` Peter Zijlstra
2011-02-01 16:22 ` Glauber Costa
2011-02-01 18:59 ` Peter Zijlstra
2011-02-01 19:55 ` Glauber Costa
2011-02-01 20:04 ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 6/6] Describe KVM_MSR_STEAL_TIME Glauber Costa
2011-01-30 13:19 ` Avi Kivity
2011-02-01 15:54 ` Glauber Costa
2011-02-02 10:14 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1296575618.5081.13.camel@mothafucka.localdomain \
--to=glommer@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox