linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Wolf <mjw@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: linux-kernel@vger.kernel.org, riel@redhat.com, gleb@redhat.com,
	kvm@vger.kernel.org, peterz@infradead.org, glommer@parallels.com,
	mingo@redhat.com, anthony@codemonkey.ws
Subject: Re: [PATCH 4/4] Add a timer to allow the separation of consigned from steal time.
Date: Tue, 05 Mar 2013 14:17:57 -0600	[thread overview]
Message-ID: <1362514677.6267.12.camel@lambeau> (raw)
In-Reply-To: <20130218235718.GB6166@amt.cnet>

Sorry for the delay in the response.  I did not see your question.

On Mon, 2013-02-18 at 20:57 -0300, Marcelo Tosatti wrote:
> On Tue, Feb 05, 2013 at 03:49:41PM -0600, Michael Wolf wrote:
> > Add a helper routine to scheduler/core.c to allow the kvm module
> > to retrieve the cpu hardlimit settings.  The values will be used
> > to set up a timer that is used to separate the consigned from the
> > steal time.
> 
> 1) Can you please describe, in english, the mechanics of subtracting cpu
> hardlimit values from steal time reported via run_delay supposed to
> work?
> 
> "The period and the quota used to separate the consigned time 
> (expected steal) from the steal time are taken
> from the cfs bandwidth control settings. Any other steal time
> accruing during that period will show as the traditional steal time."
> 
> There is no "expected steal time" over a fixed period of real time.
There is expected steal time in the sense that the administrator of the
system sets up guests on the host so that there will be cpu
overcommitment.  The end user who is using the guest does not know this,
they only know they have been guaranteed a certain level of performance.
So if steal time shows up the end user typically thinks they are not
getting their guaranteed performance. So this patchset is meant to allow
top to show 100% utilization and ONLY show steal time if it is over the
level of steal time that the host administrator setup.  So take a simple
example of a host with 1 cpu and two guest on it.  If each guest is
fully utilized a user will see 50% utilization and 50% steal in either
of the guests.  In this case the amount of steal time that the host 
administrator would expect to see is 50%.  As long as the steal in the
guest does not exceed 50% the guest is running as expected.  If for some
reason the steal increases to 60%, now something is wrong and the steal
time needs to be reported and the end user will make inquiries?

> 
> 2) From the description of patch 1: "In the case of where you have
> a system that is running in a capped or overcommitted environment 
> the user may see steal time being reported in accounting tools 
> such as top or vmstat." 
> 
> This is outdated, right? Because overcommitted environment is exactly
> what steal time should report.

I hope I'm not missing your point here.  But again this comes down to
the point of view.  The end user is guaranteed a capability/level of
performance that may not be a whole cpu.  So only show steal time if the
amount of steal time exceeds what the host admin expected when the guest
was set up.
> 
> 
> Thanks

thanks
Mike Wolf


  reply	other threads:[~2013-03-05 20:18 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 21:49 [PATCH 0/4] Alter steal-time reporting in the guest Michael Wolf
2013-02-05 21:49 ` [PATCH 1/4] Alter the amount of steal time reported by " Michael Wolf
2013-02-05 21:49 ` [PATCH 2/4] Expand the steal time msr to also contain the consigned time Michael Wolf
2013-02-06 21:14   ` Rik van Riel
2013-02-07 14:25     ` Michael Wolf
2013-02-05 21:49 ` [PATCH 3/4] Add the code to send the consigned time from the host to the guest Michael Wolf
2013-02-06 21:18   ` Rik van Riel
2013-02-07 14:26     ` Michael Wolf
2013-02-05 21:49 ` [PATCH 4/4] Add a timer to allow the separation of consigned from steal time Michael Wolf
2013-02-06 14:36   ` Glauber Costa
2013-02-06 18:07     ` Michael Wolf
2013-02-07  8:46       ` Glauber Costa
2013-02-07 14:27         ` Michael Wolf
2013-02-18 23:57   ` Marcelo Tosatti
2013-03-05 20:17     ` Michael Wolf [this message]
2013-03-06  1:35       ` Marcelo Tosatti
2013-02-18 16:43 ` [PATCH 0/4] Alter steal-time reporting in the guest Frederic Weisbecker
2013-02-19  1:11   ` Marcelo Tosatti
2013-03-05 20:22     ` Michael Wolf
2013-03-06  1:41       ` Marcelo Tosatti
2013-03-06  8:13         ` Glauber Costa
2013-03-06 16:29           ` Michael Wolf
2013-03-07  0:52             ` Marcelo Tosatti
2013-03-07  3:11               ` Paul Mackerras
2013-03-07 20:23                 ` Michael Wolf
2013-03-06 16:27         ` Michael Wolf
2013-03-07  2:30           ` Marcelo Tosatti
2013-03-07 21:09             ` Michael Wolf
2013-03-07 21:15             ` Michael Wolf
2013-03-07 21:25               ` Marcelo Tosatti
2013-03-07 22:34                 ` Michael Wolf
2013-03-08  1:54                   ` Marcelo Tosatti
2013-03-08  2:21                     ` Marcelo Tosatti
2013-03-06 13:34       ` Frederic Weisbecker
2013-03-06 16:23         ` Michael Wolf
2013-03-06 13:20     ` Frederic Weisbecker

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=1362514677.6267.12.camel@lambeau \
    --to=mjw@linux.vnet.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=gleb@redhat.com \
    --cc=glommer@parallels.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /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).