Re: vtime accounting

Christoffer Dall
2017-03-15T08:31:02Z

On Wed, Mar 15, 2017 at 09:05:28AM +0100, Paolo Bonzini wrote:
>
>
> On 14/03/2017 19:41, Christoffer Dall wrote:
> > So would it be worth considering factoring out vtime accounting from
> > guest_enter/exit, such that we could do the vtime accounting from vcpu
> > load/put and mark the RCU extended quiescent state in the run loop?
> >
> > Disclaimer: I haven't completely convinced myself that vtime accounting
> > from load/put works as it should.
>
> Me neither, but if it works, it's worth at least benchmarking it to make
> an informed decision.
>

I'll try to prototype it and see how it looks.

> > For example, when servicing a VM from
> > KVM, should we really be accounting this as kernel time, or as guest
> > time?
>
> Servicing the request should be fast enough that it doesn't matter. For
> the most common x86 vmexits, 50% of the time is spent executing the x86
> world switch microcode, and that is already being accounted as guest
> time already. On microbenchmarks of course it would make a difference:
>
> $ time ./x86/run x86/vmexit.flat -append cpuid -smp 4
> [...]
> real 0m1.327s
> user 0m1.877s << this is really guest time
> sys 0m1.844s << this is spent mostly in KVM_RUN
>
>
Good point, and if it's for statistics, this light change in behavior
can hardly constitute any form of user breakage.

Thanks,
-Christoffer