Re: vtime accounting

["Radim Krčmář" <rkrcmar@redhat.com>]

2017-03-14 19:41+0100, Christoffer Dall:
> On Tue, Mar 14, 2017 at 06:09:45PM +0100, Paolo Bonzini wrote:
>> On 14/03/2017 17:58, Radim Krčmář wrote:
>> >> I assume there's a good reason why we call guest_enter() and
>> >> guest_exit() in the hot path on every KVM architecture?
>> > I consider myself biased when it comes to jiffies, so no judgement. :)
>> > 
>> > From what I see, the mode switch is used only for statistics.
>> 
>> vtime is only for statistics, but guest_enter/exit are important because
>> they enter an RCU extended quiescent state.  This means that (physical)
>> CPUs running a guest are effectively "off" from the point of view of the
>> RCU accounting machinery.  Not having to perform any RCU work is very
>> good for jitter.

Ah, good point.

> 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?

RCU is the reason why guest_exit() needs disabled interrupts, so if we
split them, we could do rcu_virt_note_context_switch() before enabling
interrupts, and guest_exit() right after.

> Disclaimer: I haven't completely convinced myself that vtime accounting
> from load/put works as it should.  For example, when servicing a VM from
> KVM, should we really be accounting this as kernel time, or as guest
> time?  I think we do the former now, but if the latter is the right
> thing, would changing the behavior constitute an ABI change to
> userspace?

Not considering that option would be best. :)