From: Marcelo Tosatti <mtosatti@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Rik van Riel <riel@redhat.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
Peter Zijlstra <peterz@infradead.org>,
Anthony Liguori <aliguori@us.ibm.com>,
Eric B Munson <emunson@mgebm.net>
Subject: Re: [PATCH v2 3/7] KVM-HV: KVM Steal time implementation
Date: Tue, 28 Jun 2011 15:02:16 -0300 [thread overview]
Message-ID: <20110628180216.GA13513@amt.cnet> (raw)
In-Reply-To: <4E09C965.9040200@redhat.com>
On Tue, Jun 28, 2011 at 09:30:29AM -0300, Glauber Costa wrote:
> On 06/20/2011 05:56 PM, Marcelo Tosatti wrote:
> >On Sun, Jun 19, 2011 at 12:57:53PM +0300, Avi Kivity wrote:
> >>On 06/17/2011 01:20 AM, Glauber Costa wrote:
> >>>To implement steal time, we need the hypervisor to pass the guest information
> >>>about how much time was spent running other processes outside the VM.
> >>>This is per-vcpu, and using the kvmclock structure for that is an abuse
> >>>we decided not to make.
> >>>
> >>>In this patchset, I am introducing a new msr, KVM_MSR_STEAL_TIME, that
> >>>holds the memory area address containing information about steal time
> >>>
> >>>This patch contains the hypervisor part for it. I am keeping it separate from
> >>>the headers to facilitate backports to people who wants to backport the kernel
> >>>part but not the hypervisor, or the other way around.
> >>>
> >>>
> >>>
> >>>+#define KVM_STEAL_ALIGNMENT_BITS 5
> >>>+#define KVM_STEAL_VALID_BITS ((-1ULL<< (KVM_STEAL_ALIGNMENT_BITS + 1)))
> >>>+#define KVM_STEAL_RESERVED_MASK (((1<< KVM_STEAL_ALIGNMENT_BITS) - 1 )<< 1)
> >>
> >>Clumsy, but okay.
> >>
> >>>+static void record_steal_time(struct kvm_vcpu *vcpu)
> >>>+{
> >>>+ u64 delta;
> >>>+
> >>>+ if (vcpu->arch.st.stime&& vcpu->arch.st.this_time_out) {
> >>
> >>0 is a valid value for stime.
> >>
> >>>+
> >>>+ if (unlikely(kvm_read_guest(vcpu->kvm, vcpu->arch.st.stime,
> >>>+ &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) {
> >>>+
> >>>+ vcpu->arch.st.stime = 0;
> >>>+ return;
> >>>+ }
> >>>+
> >>>+ delta = (get_kernel_ns() - vcpu->arch.st.this_time_out);
> >>>+
> >>>+ vcpu->arch.st.steal.steal += delta;
> >>>+ vcpu->arch.st.steal.version += 2;
> >>>+
> >>>+ if (unlikely(kvm_write_guest(vcpu->kvm, vcpu->arch.st.stime,
> >>>+ &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)))) {
> >>>+
> >>>+ vcpu->arch.st.stime = 0;
> >>>+ return;
> >>>+ }
> >>>+ }
> >>>+
> >>>+}
> >>>+
> >>>
> >>>@@ -2158,6 +2206,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> >>> kvm_migrate_timers(vcpu);
> >>> vcpu->cpu = cpu;
> >>> }
> >>>+
> >>>+ record_steal_time(vcpu);
> >>> }
> >>
> >>This records time spent in userspace in the vcpu thread as steal
> >>time. Is this what we want? Or just time preempted away?
> >
> >It also accounts halt time (kvm_vcpu_block) as steal time. Glauber, you
> >could instead use the "runnable-state-but-waiting-in-runqueue" field of
> >SCHEDSTATS, i forgot the exact name.
> >
> I thought about it in the past. I let the idea aside because I
> didn't want to introduce a dependency on SCHEDSTATS. But thinking
> about it again now (and after some days of experimentations with
> it), I think we could have both.
>
> use run_delay (the field you were thinking of) when schedstats are
> available, and fallback to an estimate method like the one we're
> doing when it is not.
>
> Objections ?
I'm okay with that.
next prev parent reply other threads:[~2011-06-28 19:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 22:20 [PATCH v2 0/7] Steal time for KVM Glauber Costa
2011-06-16 22:20 ` [PATCH v2 1/7] KVM-HDR Add constant to represent KVM MSRs enabled bit Glauber Costa
2011-06-17 0:47 ` Eric B Munson
2011-06-16 22:20 ` [PATCH v2 2/7] KVM-HDR: KVM Steal time implementation Glauber Costa
2011-06-17 0:48 ` Eric B Munson
2011-06-19 9:49 ` Avi Kivity
2011-06-20 2:55 ` Glauber Costa
2011-06-16 22:20 ` [PATCH v2 3/7] KVM-HV: " Glauber Costa
2011-06-17 0:48 ` Eric B Munson
2011-06-19 9:57 ` Avi Kivity
2011-06-20 2:53 ` Glauber Costa
2011-06-20 6:02 ` Avi Kivity
2011-06-20 20:56 ` Marcelo Tosatti
2011-06-28 12:30 ` Glauber Costa
2011-06-28 18:02 ` Marcelo Tosatti [this message]
2011-06-16 22:20 ` [PATCH v2 4/7] KVM-GST: Add a pv_ops stub for steal time Glauber Costa
2011-06-17 0:48 ` Eric B Munson
2011-06-16 22:20 ` [PATCH v2 5/7] KVM-GST: KVM Steal time accounting Glauber Costa
2011-06-17 0:48 ` Eric B Munson
2011-06-19 10:04 ` Avi Kivity
2011-06-20 2:38 ` Glauber Costa
2011-06-20 6:07 ` Avi Kivity
2011-06-16 22:20 ` [PATCH v2 6/7] KVM-GST: adjust scheduler cpu power Glauber Costa
2011-06-17 0:49 ` Eric B Munson
2011-06-19 10:05 ` Avi Kivity
2011-06-16 22:20 ` [PATCH v2 7/7] KVM-GST: KVM Steal time registration Glauber Costa
2011-06-17 0:49 ` Eric B Munson
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=20110628180216.GA13513@amt.cnet \
--to=mtosatti@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=emunson@mgebm.net \
--cc=glommer@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