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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2015-07-10 at 09:47 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 10, 2015 at 02:40:17PM +0200, Dario Faggioli wrote:

> > 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.
>
It sure does, and it is in its own full right of doing it! I think I
said that they're there for accounting and information reporting to
upper layer, and Linux is what populates one of the (various) upper
layers, as far as Xen is concerned, isn't it?

What I'm arguing about is not them being there at all, nor about them
being used for their own purpose, it's much rather about them being
(ab)used for hardware enablement _in_Xen_ itself. :-)

> > 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!
>
Hey, I said 'theoretically speaking'! :-)

I don't have, and am not aware of any other plan to get rid of them..
So, fear nothing, they're not going anywhere... are are they?
Mhwuawhuahwua :-D :-D

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel