Re: [Xen-devel] RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/23/2014 10:28 PM, Konrad Rzeszutek Wilk wrote:
> What we are observing is that if a domain is idle its steal
> time* goes up. My first thought was - well that is the initial
> domain taking the time - but after looking at the trace
> did not see the initial domain to be scheduled at all.
>
> (*steal time: RUNSTATE_runnable + RUNSTATE_offline).
"Up" like how much?

Steal time includes the time *being woken* up.  It takes time to be 
woken up; typically if it's being woken up from domain 0, for instance, 
the wake (which sets it to RUNSTATE_runnable) will happen on a different 
pcpu than the vcpu being woken is on, so there's the delay of the IPI, 
waking up, going through the scheduler, &c.
The more frequently a VM is already running, the lower probability that 
an interrupt will actually wake it up.
BTW, is there a reason you're using xentrace_format instead of xenalyze?

hg clone http://xenbits.xenproject.org/ext/xenalyze

Unlike xentrace_format, xenalyze can:
1. Report the trace records in the order they happened across all pcpus, 
so you can see interactions between pcpus
2. Do its own runstate analysis on a per-vcpu level, allowing you to see 
not only how much time was spent in the "runnable" state, but how much 
of it was due to being woken up vs being preempted.
3. Allow you to see statistics on how long the "waking up" process took 
(average, and 5th/50th/95th %ile)
4. Give you a framework to allow you to easily add your own analysis if 
you want.  For instance, you could add statistics for how often a vcpu 
was woken up due to a local timer event vs woken up by an event from 
dom0 on another cpu, &c.
 -George


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