Re: [Xen-devel] Xen Platform QoS design discussion

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/14 03:34, Xu, Dongxiao wrote:
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> Sent: Friday, May 02, 2014 8:51 PM
>> To: Xu, Dongxiao
>> Cc: Jan Beulich; Ian Campbell; xen-devel@xxxxxxxxxxxxx
>> Subject: Re: Xen Platform QoS design discussion
>>
>> On 02/05/14 13:30, Xu, Dongxiao wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>> Sent: Friday, May 02, 2014 5:24 PM
>>>> To: Xu, Dongxiao
>>>> Cc: Andrew Cooper(andrew.cooper3@xxxxxxxxxx); Ian Campbell;
>>>> xen-devel@xxxxxxxxxxxxx
>>>> Subject: RE: Xen Platform QoS design discussion
>>>>
>>>>>>> On 01.05.14 at 02:56, <dongxiao.xu@xxxxxxxxx> wrote:
>>>>>> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
>>>>>> Have you asked yourself whether this information even needs to be
>>>>>> exposed all the way up to libxl? Who are the expected consumers of this
>>>>>> interface? Are they low-level CLI tools (i.e. like xenpm is) or are you
>>>>>> expecting toolstacks to plumb this information all the way up to their
>>>>>> GUI or CLI (e.g. xl or virsh)?
>>>>> The information returned to libxl users is the cache utilization for a
>>>>> certain domain in certain socket, and the main consumers are cloud users
>> like
>>>>> openstack, etc. Of course, we will also provide an xl command to present
>> such
>>>>> information.
>>>> To me this doesn't really address the question Ian asked, yet knowing
>>>> who's going to be the consumer of the data is also quite relevant for
>>>> answering your original question on the method to obtain that data.
>>>> Obviously, if the main use of it is per-domain, a domctl would seem like
>>>> a suitable approach despite the data being more of sysctl kind. But if
>>>> a global view would be more important, that model would seem to make
>>>> life needlessly hard for the consumers. In turn, if using a domctl, I tend
>>>> to agree that not using shared pages would be preferable; iirc their use
>>>> was mainly suggested because of the size of the data.
>>> From the discussion with openstack developers, on certain cloud host, all
>> running VM's information (e.g., domain ID) will be stored in a database, and
>> openstack software will use libvirt/XenAPI to query specific domain 
>> information.
>> That libvirt/XenAPI API interface basically accepts the domain ID as input
>> parameter and get the domain information, including the platform QoS one.
>>> Based on above information, I think we'd better design the QoS hypercall
>> per-domain.
>>
>> The design of the hypercall has nothing to do with the design of the
>> libxl/XenAPI interface.
> If use the share mechanism between Xen and Dom0 user space, plus explicitly 
> listing all the available CQM features as you proposed (see below structure 
> cited from previous mail), then the ABI between Xen and Dom0 user space may 
> need to be changing every time when a new QoS feature is introduced, which 
> breaks the compatibility to some extent. :(

Not in the slightest.  Xen and libxc are required to be a matching set,
compiled from the same changeset.  There are no problems at all changing
structures like this going forwards.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel