Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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!