lkml.org 
[lkml]   [2012]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC 0/3] Add guest cpu_entitlement reporting
Date
Avi Kivity <avi@redhat.com> writes:

> On 08/27/2012 02:27 PM, Michael Wolf wrote:
>> On Mon, 2012-08-27 at 13:31 -0700, Avi Kivity wrote:
>> > On 08/27/2012 01:23 PM, Michael Wolf wrote:
>> > > >
>> > > > How would a guest know what its entitlement is?
>> > > >
>> > > >
>> > >
>> > > Currently the Admin/management tool setting up the guests will put it on
>> > > the qemu commandline. From this it is passed via an ioctl to the host.
>> > > The guest will get the value from the host via a hypercall.
>> > >
>> > > In the future the host could try and do some of it automatically in some
>> > > cases.
>> >
>> > Seems to me it's a meaningless value for the guest. Suppose it is
>> > migrated to a host that is more powerful, and as a result its relative
>> > entitlement is reduced. The value needs to be adjusted.
>>
>> This is why I chose to manage the value from the sysctl interface rather
>> than just have it stored as a value in /proc. Whatever tool was used to
>> migrate the vm could hopefully adjust the sysctl value on the guest.
>
> We usually try to avoid this type of coupling. What if the guest is
> rebooting while this is happening? What if it's not running Linux at
> all?

The guest shouldn't need to know it's entitlement. Or at least, it's up
to a management tool to report that in a way that's meaningful for the
guest.

For instance, with a hosting provider, you may have 3 service levels
(small, medium, large). How you present whether the guest is small,
medium, or large to the guest is up to the hosting provider.

>
>> >
>> > This is best taken care of from the host side.
>>
>> Not sure what you are getting at here. If you are running in a cloud
>> environment, you purchase a VM with the understanding that you are
>> getting certain resources. As this type of user I don't believe you
>> have any access to the host to see this type of information. So the
>> user still wouldnt have a way to confirm that they are receiving what
>> they should be in the way of processor resources.
>>
>> Would you please elaborate a little more on this?
>
> I meant not reporting this time as steal time. But that cripples steal
> time reporting.
>
> Looks like for each quanta we need to report how much real time has
> passed, how much the guest was actually using, and how much the guest
> was not using due to overcommit (with the reminder being unallocated
> time). The guest could then present it any way it wanted to.

What I had previously suggested what splitting entitlement loss out of
steal time and reporting it as a separate metric (but not reporting a
fixed notion of entitlement).

You're missing the entitlement loss bit above. But you need to call
out entitlement loss in order to report idle time correctly.

I think changing steal time (as this patch does) is wrong.

Regards,

Anthony Liguori

>
> --
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


\
 
 \ /
  Last update: 2012-08-28 18:41    [W:0.071 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site