Re: [PATCH v2 3/7] KVM-HV: KVM Steal time implementation

[Avi Kivity]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/