From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen Platform QoS design discussion Date: Tue, 6 May 2014 10:12:11 +0100 Message-ID: <1399367531.3014.34.camel@kazak.uk.xensource.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: Andrew Cooper , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Sun, 2014-05-04 at 02:34 +0000, 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. :( This is generally acceptable for a domctl, although if it can be defined to avoid it even better. This isn't acceptable for the libxl layer interface though, there API compatibility is required.