From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Fri, 10 Jul 2015 09:47:13 -0400 Message-ID: <20150710134713.GJ23038@l.oracle.com> References: <55918214.4030102@citrix.com> <1435633087.25170.274.camel@citrix.com> <1435825253.25170.406.camel@citrix.com> <1436445732.22672.321.camel@citrix.com> <1436532017.22672.411.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1436532017.22672.411.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: "Tian, Kevin" , "keir@xen.org" , George Dunlap , "andrew.cooper3@citrix.com" , xen-devel , "jbeulich@suse.com" , "Zhang, Yang Z" , "Wu, Feng" List-Id: xen-devel@lists.xenproject.org On Fri, Jul 10, 2015 at 02:40:17PM +0200, Dario Faggioli wrote: > On Fri, 2015-07-10 at 00:07 +0000, Wu, Feng wrote: > > > > From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > > > > What I mean is, can you describe when you need each specific operation > > > needs to happen? Something like "descriptor needs to be updated like > > > this upon migration", "notification should be disabled when vcpu starts > > > running", "notification method should be changed that other way when > > > vcpu is preempted", etc. > > > > I cannot see the differences, I think the requirements are clearly listed in > > the design doc and the comments of this patch. > > > The difference is, and is IMO quite a big one, this: do you need to do > something when a vcpu wakes up, perhaps depending whether it is runnable > or not immediately after that, or when a vcpu enters runstate > RUNSTATE_runnable. > > IOW, are you interested in the event, or in the change that such an > event causes, as far as a particular subsystem (in this case > accounting/information reporting) is concerned? > > And no, the fact that when a vcpu wakes up, if it's runnable, it enters > te RUNSTATE_runnable runstate is not enough to say that they're the same > thing! Runstate are an abstraction used for accounting and for reporting > information to the higher levels. > So, why not use it? No reason, and in fact it's used a lot! For > instance, xenalyze (and tracing in general) uses it; getdomaininfo() > uses it; XEN_DOMCTL_getvcpuinfo uses it. > > However, there is no one single feature (e.g., for hardware enablement, > like yours) that I can find, within Xen, that builds on top of runstates > (the only exception is credit1 scheduler, and only it, using > runstate.state_entry_time once... and I think that's quite bad of it, > FWIW). Linux kernel uses them. It ends up reporting the values for 'steal time' as the RUNSTATE_runnable. Aka if you run 'top' and see 'st' - that is it. > > Theoretically speaking, runstates could well disappear, or change > meaning, or be replaced by something else, and only the accounting and > reporting code (as far as the hypervisor is concerned, of course) would > suffer/need changing. Please don't remove them! They helped me in tracking down a situation where guests had 20% of them time-slice taken out by a global spinlock!