On 06/20/2011 05:53 AM, Glauber Costa wrote:
+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.
how exactly? stime is a guest physical address...
0 is a valid physical address.
@@ -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?
There are arguments either way.
Right now, the way it is, it does account our iothread as steal time,
which is not 100 % accurate if we think steal time as "whatever takes
time away from our VM". I tend to think it as "whatever takes time
away from this CPU", which includes other cpus in the same VM. So
thinking this way, in a 1-1 phys-to-virt cpu mapping, if the iothread
is taking 80 % cpu for whatever reason, we have 80 % steal time the
cpu that is sharing the physical cpu with the iothread.
I'm not talking about the iothread, rather the vcpu thread while running
in userspace.
Maybe we could account that as iotime ?
Questions like that are one of the reasons behind me leaving extra
fields in the steal time structure. We could do a more fine grained
accounting and differentiate between the multiple entities that can do
work (of various kinds) in our behalf.
What do other architectures do (xen, s390)?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
