From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Xen Platform QoS design discussion Date: Tue, 6 May 2014 11:00:09 +0100 Message-ID: <5368B2A9.9070808@citrix.com> References: <40776A41FC278F40B59438AD47D147A9119F3FEA@SHSMSX104.ccr.corp.intel.com> <1398877340.5166.13.camel@kazak.uk.xensource.com> <40776A41FC278F40B59438AD47D147A9119F42A2@SHSMSX104.ccr.corp.intel.com> <5363804B020000780000E604@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A9119F4EF4@SHSMSX104.ccr.corp.intel.com> <536394A1.6040500@citrix.com> <40776A41FC278F40B59438AD47D147A9119F59D0@SHSMSX104.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <40776A41FC278F40B59438AD47D147A9119F59D0@SHSMSX104.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Xu, Dongxiao" Cc: Ian Campbell , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 04/05/14 03:34, Xu, Dongxiao wrote: >> -----Original Message----- >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com] >> Sent: Friday, May 02, 2014 8:51 PM >> To: Xu, Dongxiao >> Cc: Jan Beulich; Ian Campbell; xen-devel@lists.xen.org >> Subject: Re: Xen Platform QoS design discussion >> >> On 02/05/14 13:30, Xu, Dongxiao wrote: >>>> -----Original Message----- >>>> From: Jan Beulich [mailto:JBeulich@suse.com] >>>> Sent: Friday, May 02, 2014 5:24 PM >>>> To: Xu, Dongxiao >>>> Cc: Andrew Cooper(andrew.cooper3@citrix.com); Ian Campbell; >>>> xen-devel@lists.xen.org >>>> Subject: RE: Xen Platform QoS design discussion >>>> >>>>>>> On 01.05.14 at 02:56, wrote: >>>>>> From: Ian Campbell [mailto:Ian.Campbell@citrix.com] >>>>>> 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