From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: vtime accounting Date: Tue, 14 Mar 2017 22:52:29 +0100 Message-ID: <20170314215229.GE5432@potion> References: <20170308105700.GA109453@lvm> <20170313162259.GE18298@potion> <20170314082601.GC1277@cbox> <20170314165858.GA5435@potion> <1d205be1-50ab-59cf-9908-dbbe8c939309@redhat.com> <20170314184133.GG1277@cbox> <20170314193201.GC5432@potion> <20170314200147.GH1277@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Paolo Bonzini , Christoffer Dall , kvm@vger.kernel.org, Marc Zyngier , Rik van Riel To: Christoffer Dall Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44880 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751707AbdCNVwe (ORCPT ); Tue, 14 Mar 2017 17:52:34 -0400 Content-Disposition: inline In-Reply-To: <20170314200147.GH1277@cbox> Sender: kvm-owner@vger.kernel.org List-ID: 2017-03-14 21:01+0100, Christoffer Dall: > On Tue, Mar 14, 2017 at 08:32:02PM +0100, Radim Krčmář wrote: >> 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. >> > > I'm not convinced that what you're saying is true ;) I agree. > I think we only fiddle with RCU during guest_enter, and further, a trace > of guest_exit reveals: > > guest_exit_irqoff > -> vtime_guest_exit > -> __vtime_account_system > -> get_vtime_delta > -> account_other_time > -> WARN_ON_ONCE(!irqs_disabled()); > > So I think we do need interrupts disabled when messing with vtime? Seem like it. >> > 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. :) > > If my statement above about needing interrupts disabled when dealing > with vtime, then considering this begins to sound interesting, also > given that the vtime thing is not entirely free and we're dealing with > the hot path of receiving IPIs here, for example. I'm liking it less and less the more I read. :) CONTEXT_USER vtime is coupled with context tracking and going out of CONTEXT_KERNEL means that RCU cannot be used in between. Using CONTEXT_GUEST from load/put would change the meaning of contexts ...