From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen Platform QoS design discussion Date: Thu, 5 Jun 2014 11:43:22 +0100 Message-ID: References: <40776A41FC278F40B59438AD47D147A9119F3FEA@SHSMSX104.ccr.corp.intel.com> <5363804B020000780000E604@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A9119F4EF4@SHSMSX104.ccr.corp.intel.com> <5363AE54020000780000E7A2@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A9119FE6BB@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> <538707E202000078000B5293@mail.emea.novell.com> <1401441052.15871.55.camel@hastur.hellion.org.uk> <538876DA02000078000B5403@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A911A27FDE@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: <40776A41FC278F40B59438AD47D147A911A27FDE@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@citrix.com" , "andrew.cooper3@citrix.com" , "xen-devel@lists.xen.org" , "Auld, Will" , Jan Beulich , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org On Thu, Jun 5, 2014 at 1:48 AM, Xu, Dongxiao wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:jbeulich@suse.com] >> Sent: Friday, May 30, 2014 7:18 PM >> To: ian.campbell@citrix.com >> Cc: andrew.cooper3@citrix.com; george.dunlap@eu.citrix.com; Xu, Dongxiao; >> Nakajima, Jun; Auld, Will; xen-devel@lists.xen.org >> Subject: Re: RE: RE: [Xen-devel] Xen Platform QoS design discussion >> >> >>> Ian Campbell 05/30/14 11:11 AM >>> >> >On Thu, 2014-05-29 at 10:11 +0100, Jan Beulich wrote: >> >> >>> "Xu, Dongxiao" 05/29/14 9:31 AM >>> >> >> >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. >> >> >> >> I am okay with it, but give it a couple of days before you start so that others >> >> can voice their opinions too. >> > >> >Dom0 may not have a vcpu which is scheduled/schedulable on every socket. >> >scheduled it can probably deal with by doing awful sounding temporary >> >things to its affinity mask, but if it is not schedulable (e.g. due to >> >cpupools etc) then that sounds even harder to sort... >> >> But that's why we're intending to add a helper hypercall in the first place. This >> isn't intended to be a 'read MSR' one, but a 'read MSR in this CPU'. > > No more comments on this MSR access hypercall design now, so I assume people are mostly okay with it? Yes -- I think everyone who commented before is satisfied with that approach, and anyone who hasn't commented has had ample opportunity to do so. -George