From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xu, Dongxiao" Subject: Re: Xen Platform QoS design discussion Date: Fri, 30 May 2014 01:07:28 +0000 Message-ID: <40776A41FC278F40B59438AD47D147A911A20F78@SHSMSX104.ccr.corp.intel.com> References: <40776A41FC278F40B59438AD47D147A9119F3FEA@SHSMSX104.ccr.corp.intel.com> <5368B418.9000307@citrix.com> <536AA342.8030003@citrix.com> <40776A41FC278F40B59438AD47D147A911A00A4C@SHSMSX104.ccr.corp.intel.com> <536B69AB.7010005@citrix.com> <40776A41FC278F40B59438AD47D147A911A150FC@SHSMSX104.ccr.corp.intel.com> <537A0B17020000780001390F@mail.emea.novell.com> <5379F576.4050108@eu.citrix.com> <537A18260200007800013A06@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A911A1AAEC@SHSMSX104.ccr.corp.intel.com> <537DD3E60200007800014CFD@mail.emea.novell.com> <537DC2F2.30702@eu.citrix.com> <40776A41FC278F40B59438AD47D147A911A206A4@SHSMSX104.ccr.corp.intel.com> <5386E96402000078000B525D@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A911A20944@SHSMSX104.ccr.corp.intel.com> <5386FA3C.3010201@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5386FA3C.3010201@citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Jan Beulich , "george.dunlap@eu.citrix.com" Cc: "Auld, Will" , "Ian.Campbell@citrix.com" , "Nakajima, Jun" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > On 29/05/2014 08:31, Xu, Dongxiao wrote: > >> -----Original Message----- > > Okay. If I understand correctly, you prefer to implement a pure MSR access > hypercall for one CPU, and put all other CQM things in libxc/libxl layer. > > > > In this case, if libvert/XenAPI is trying to query a domain's cache utilization in > the system (say 2 sockets), then it will trigger _two_ such MSR access hypercalls > for CPUs in the 2 different sockets. > > If you are okay with this idea, I am going to implement it. > > > > Thanks, > > Dongxiao > > While I can see the use and attraction of a generic MSR access > hypercalls, using this method for getting QoS data is going to have > subsantitally higher overhead than even the original domctl suggestion. > > I do not believe it will be an effective means of getting large > quantities of data from ring0 MSRs into dom0 userspace. This is not to > say that having a generic MSR interface is a bad thing, but I don't > think it should be used for this purpose. They are the two directions to implement this feature: Generic MSR access hypercall: It removes most of the policy in hypervisor and put them in Dom0 userspace, which makes the implementation in hypervisor very simple, with slightly higher cost (more hypercalls). Sysctl hypercall: Hypervisor needs to consolidate all the CQM data which burdens the implementation, with more memory allocation, data sharing mechanism (2-level, page's address page, and page itself), also more policies in hypervisor, etc. While its cost is slightly less. In my opinion, domctl is a compromise between two approaches, with moderate policies in hypervisor, moderate size of memory allocation, with moderate cost. I would prefer domctl or generic MSR access way, which makes the implementation in hypervisor simple enough, but with only slightly higher cost. Thanks, Dongxiao > > ~Andrew