xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xenproject.org, dario.faggioli@citrix.com
Subject: Re: RUNSTATE_runnable delta time for idle_domain accounted to HVM guest.
Date: Tue, 29 Apr 2014 10:16:39 +0100	[thread overview]
Message-ID: <535F6DF7.9080704@eu.citrix.com> (raw)
In-Reply-To: <20140423212824.GB12560@phenom.dumpdata.com>

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

  parent reply	other threads:[~2014-04-29  9:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 21:28 RUNSTATE_runnable delta time for idle_domain accounted to HVM guest Konrad Rzeszutek Wilk
2014-04-24  7:58 ` Jan Beulich
2014-04-24 18:02   ` Konrad Rzeszutek Wilk
2014-04-29  9:16 ` George Dunlap [this message]
2014-04-29 12:42   ` Konrad Rzeszutek Wilk
2014-05-06 17:36     ` Konrad Rzeszutek Wilk
2014-05-07  8:07       ` Jan Beulich
2014-05-07 13:33         ` Konrad Rzeszutek Wilk
2014-05-07 14:10           ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=535F6DF7.9080704@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).