From: Glauber Costa <glommer@parallels.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Michael Wolf <mjw@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
<linux-kernel@vger.kernel.org>, <riel@redhat.com>,
<gleb@redhat.com>, <kvm@vger.kernel.org>, <peterz@infradead.org>,
<mingo@redhat.com>, <anthony@codemonkey.ws>
Subject: Re: [PATCH 0/4] Alter steal-time reporting in the guest
Date: Wed, 6 Mar 2013 12:13:40 +0400 [thread overview]
Message-ID: <5136FAB4.4020305@parallels.com> (raw)
In-Reply-To: <20130306014151.GB11481@amt.cnet>
On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
> On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
>> Sorry for the delay in the response. I did not see the email
>> right away.
>>
>> On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
>>> On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
>>>> 2013/2/5 Michael Wolf <mjw@linux.vnet.ibm.com>:
>>>>> 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 can
>>>>> cause confusion for the end user.
>>>>
>>>> Sorry, I'm no expert in this area. But I don't really understand what
>>>> is confusing for the end user here.
>>>
>>> I suppose that what is wanted is to subtract stolen time due to 'known
>>> reasons' from steal time reporting. 'Known reasons' being, for example,
>>> hard caps. So a vcpu executing instructions with no halt, but limited to
>>> 80% of available bandwidth, would not have 20% of stolen time reported.
>>
>> Yes exactly and the end user many times did not set up the guest and is
>> not aware of the capping. The end user is only aware of the performance
>> level that they were told they would get with the guest.
>>> But yes, a description of the scenario that is being dealt with, with
>>> details, is important.
>>
>> I will add more detail to the description next time I submit the
>> patches. How about something like,"In a cloud environment the user of a
>> kvm guest is not aware of the underlying hardware or how many other
>> guests are running on it. The end user is only aware of a level of
>> performance that they should see." or does that just muddy the picture
>> more??
>
> So the feature aims for is to report stolen time relative to hard
> capping. That is: stolen time should be counted as time stolen from
> the guest _beyond_ hard capping. Yes?
>
> Probably don't need to report new data to the guest for that.
>
If we take into account that 1 second always have one second, I believe
that you can just subtract the consigned time from the steal time the
host passes to the guest.
During each second, the numbers won't sum up to 100. The delta to 100 is
the consigned time, if anyone cares.
Adopting this would simplify this a lot. All you need to do, really, is
to get your calculation right from the bandwidth given by the cpu
controller. Subtract it in the host, and voila.
next prev parent reply other threads:[~2013-03-06 8:13 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 [this message]
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=5136FAB4.4020305@parallels.com \
--to=glommer@parallels.com \
--cc=anthony@codemonkey.ws \
--cc=fweisbec@gmail.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjw@linux.vnet.ibm.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