From: Glauber Costa <glommer@parallels.com>
To: <mjw@linux.vnet.ibm.com>
Cc: <linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org>,
<peterz@infradead.org>, <mtosatti@redhat.com>, <mingo@redhat.com>,
<avi@redhat.com>
Subject: Re: [PATCH RFC 0/3] Add guest cpu_entitlement reporting
Date: Mon, 27 Aug 2012 13:51:55 -0700 [thread overview]
Message-ID: <503BDDEB.7090901@parallels.com> (raw)
In-Reply-To: <1346098754.8623.19.camel@lambeau>
On 08/27/2012 01:19 PM, Michael Wolf wrote:
> On Mon, 2012-08-27 at 11:50 -0700, Glauber Costa wrote:
>> On 08/27/2012 08:50 AM, Michael Wolf wrote:
>>> On Sat, 2012-08-25 at 19:36 -0400, Glauber Costa wrote:
>>>> On 08/24/2012 11:11 AM, Michael Wolf wrote:
>>>>> On Fri, 2012-08-24 at 08:53 +0400, Glauber Costa wrote:
>>>>>> On 08/24/2012 03:14 AM, Michael Wolf wrote:
>>>>>>> This is an RFC regarding the reporting of stealtime. In the case of
>>>>>>> where you have a system that is running with partial processors such as
>>>>>>> KVM the user may see steal time being reported in accounting tools such
>>>>>>> as top or vmstat. This can cause confusion for the end user. To
>>>>>>> ease the confusion this patch set adds a sysctl interface to set the
>>>>>>> cpu entitlement. This is the percentage of cpu that the guest system is
>>>>>>> expected to receive. As long as the steal time is within its expected
>>>>>>> range it will show up as 0 in /proc/stat. The user will then see in the
>>>>>>> accounting tools that they are getting a full utilization of the cpu
>>>>>>> resources assigned to them.
>>>>>>>
>>>>>>
>>>>>> And how is such a knob not confusing?
>>>>>>
>>>>>> Steal time is pretty well defined in meaning and is shown in top for
>>>>>> ages. I really don't see the point for this.
>>>>>
>>>>> Currently you can see the steal time but you have no way of knowing if
>>>>> the cpu utilization you are seeing on the guest is the expected amount.
>>>>> I decided on making it a knob because a guest could be migrated to
>>>>> another system and it's entitlement could change because of hardware or
>>>>> load differences. It could simply be a /proc file and report the
>>>>> current entitlement if needed. As things are currently implemented I
>>>>> don't see how someone knows if the guest is running as expected or
>>>>> whether there is a problem.
>>>>>
>>>>
>>>> Turning off steal time display won't get even close to displaying the
>>>> information you want. What you probably want is a guest-visible way to
>>>> say how many miliseconds you are expected to run each second. Right?
>>>
>>> It is not clear to me how knowing how many milliseconds you are
>>> expecting to run will help the user. Currently the users will run top
>>> to see how well the guest is running. If they see _any_ steal time some
>>> users think they are not getting the full use of their processor
>>> entitlement.
>>>
>>
>> And your plan is just to selectively lie about it, but disabling it with
>> a knob?
>
> It is about making it very obvious to the end user whether they are
> receiving their cpu entitlement. If there is more steal time than
> expected that will still show up. I have experimented, and it seems to
> work, to put the raw stealtime at the end of each cpu line
> in /proc/stat. That way the raw data is there as well.
>
> Do you have another suggestion to communicate to the user whether they
> are receiving their full entitlement? At the very least shouldn't the
> entitlement reside in a /proc file somewhere so that the user could look
> up the value and "do the math"?
>
I personally believe Avi is right here. This is something to be done at
the host side. The user can learn this from any tool he is using to
manage his VMs.
Now if you absolutely must inform him from inside the guest, I would go
with the later, informing him in another location. (I am not saying I
agree with this, just that this is less worse)
next prev parent reply other threads:[~2012-08-27 20:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-23 23:14 [PATCH RFC 0/3] Add guest cpu_entitlement reporting Michael Wolf
2012-08-23 23:14 ` [PATCH RFC 1/3] Add a sysctl interface to control and report the cpu entitlement setting Michael Wolf
2012-08-23 23:14 ` [PATCH RFC 2/3] Add a hypercall to retrieve the cpu entitlement value from the host Michael Wolf
2012-08-23 23:14 ` [PATCH RFC 3/3] Modify the amount of stealtime that the kernel reports via the /proc interface Michael Wolf
2012-08-24 4:53 ` [PATCH RFC 0/3] Add guest cpu_entitlement reporting Glauber Costa
2012-08-24 15:11 ` Michael Wolf
2012-08-25 23:36 ` Glauber Costa
2012-08-27 15:50 ` Michael Wolf
2012-08-27 18:50 ` Glauber Costa
2012-08-27 20:19 ` Michael Wolf
2012-08-27 20:51 ` Glauber Costa [this message]
2012-08-27 18:55 ` Avi Kivity
2012-08-27 20:23 ` Michael Wolf
2012-08-27 20:31 ` Avi Kivity
2012-08-27 21:27 ` Michael Wolf
2012-08-27 21:41 ` Glauber Costa
2012-08-27 21:53 ` Michael Wolf
2012-08-27 21:52 ` Avi Kivity
2012-08-28 16:01 ` Anthony Liguori
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=503BDDEB.7090901@parallels.com \
--to=glommer@parallels.com \
--cc=avi@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 \
/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).