From: Michael Wolf <mjw@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
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 0/4] Alter steal-time reporting in the guest
Date: Thu, 07 Mar 2013 16:34:16 -0600 [thread overview]
Message-ID: <1362695656.31276.37.camel@lambeau> (raw)
In-Reply-To: <20130307212552.GB22196@amt.cnet>
On Thu, 2013-03-07 at 18:25 -0300, Marcelo Tosatti wrote:
> On Thu, Mar 07, 2013 at 03:15:09PM -0600, Michael Wolf wrote:
> > >
> > > Makes sense?
> > >
> > > Not sure what the concrete way to report stolen time relative to hard
> > > capping is (probably easier inside the scheduler, where run_delay is
> > > calculated).
> > >
> > > Reporting the hard capping to the guest is a good idea (which saves the
> > > user from having to measure it themselves), but better done separately
> > > via new field.
> >
> > didnt respond to this in the previous response. I'm not sure I'm
> > following you here. I thought this is what I was doing by having a
> > consigned (expected steal) field add to the /proc/stat output. Are you
> > looking for something else or a better naming convention?
>
> Expected steal is not a good measure to use (because as mentioned in the
> previous email there is no expected steal over a fixed period of time).
>
> It is fine to report 'maximum percentage of underlying physical CPU'
> (what percentage of the physical CPU time guest VM is allowed to make
> use of).
>
> And then steal time is relative to maximum percentage of underlying
> physical CPU time allowed.
>
So last August I had sent out an RFC set of patches to do this. That
patchset was meant to handle the general overcommit case as well as the
capping case by having qemu pass a percentage to the host that would
then be passed onto the guest and used to adjust the steal time.
Here is the link to the discussion
http://lkml.indiana.edu/hypermail/linux/kernel/1208.3/01458.html
As you will see there Avi didn't like the idea of a percentage down in
the guest, among other reasons he was concerned about migration. Also
in the email thread you will see that Anthony Liguori was opposed to the
idea of just changing the steal time, he wanted it split out.
What Glauber has suggested and I am working on implementing is taking
out the timer and adding a last read field in the host. So in the host
I can determine the total time that has passed and compute a percentage
and apply that percentage to the steal time while the info is still on
the host. Then pass the steal and consigned time to the guest.
Does that address your concerns?
next prev parent reply other threads:[~2013-03-07 22:34 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
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 [this message]
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=1362695656.31276.37.camel@lambeau \
--to=mjw@linux.vnet.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=fweisbec@gmail.com \
--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