From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 0/9] Porting the intel_pstate driver to Xen Date: Fri, 24 Apr 2015 12:14:38 -0400 Message-ID: <20150424161437.GC8117@konrad-lan.dumpdata.com> References: <553A249E0200007800075817@mail.emea.novell.com> <286AC319A985734F985F78AFA26841F78D267F@shsmsx102.ccr.corp.intel.com> <553A2F3D0200007800075876@mail.emea.novell.com> <286AC319A985734F985F78AFA26841F78D26D1@shsmsx102.ccr.corp.intel.com> <553A34C602000078000758B4@mail.emea.novell.com> <286AC319A985734F985F78AFA26841F78D27B4@shsmsx102.ccr.corp.intel.com> <553A598B0200007800075973@mail.emea.novell.com> <286AC319A985734F985F78AFA26841F78D294A@shsmsx102.ccr.corp.intel.com> <553A77470200007800075A62@mail.emea.novell.com> <286AC319A985734F985F78AFA26841F78D29DC@shsmsx102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <286AC319A985734F985F78AFA26841F78D29DC@shsmsx102.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: "Wang, Wei W" Cc: "Tian, Kevin" , "ian.campbell@citrix.com" , "andrew.cooper3@citrix.com" , "Dong, Eddie" , "xen-devel@lists.xen.org" , Jan Beulich , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org On Fri, Apr 24, 2015 at 03:42:40PM +0000, Wang, Wei W wrote: > On 24/04/2015 23:04, Jan Beulich wrote > > >>> On 24.04.15 at 16:56, wrote: > > > On 24/04/2015 20:57, Jan Beulich wrote > > >> I'm not sure how else to express what I want (no matter how many > > >> internal governors the intel_pstate driver has). > > >> > > >> xenpm set-scaling-governor powersave > > >> xenpm set-scaling-governor ondemand > > >> xenpm set-scaling-governor performance > > >> > > >> each should switch the system into a respective state, no matter > > >> whether internally to the driver this means a change of governors or > > >> just a modification to {min,max}_pct. > > >> > > >> And obtaining the current state after any of the above should show > > >> the same governor in use that was set (and not "internal"), again no > > >> matter how this is being achieved internally to the driver. > > > > > > Thanks Jan, that's clear. But this will have another issue. For > > > example, we set-scaling-governor to "ondemand", then we adjust > > > min_pct=max_pct = 60%. The timer function may generate results like > > > 35%, 55%, 45%..., but the CPU just keeps running with 60%. > > > > So I must be misunderstanding something then: How can the driver do > > anything at all when told to run the system at 60%? > > The {min,max}_pct is a limit. The timer function figures out a proper value based on the sampled statistics, then this value is clamped into [min_pct, max_pct]. When we have [60%, 60%], whatever the value from the timer function is, it will be finally adjusted to 60%, and set to the perf_ctl register. > > > > Then, this is not "ondemand" at all (I think this should be another > > > reason why the intel_pstate driver does not call its governor > > > "ondemand"). > > > > > > The intel_pstate driver in the kernel has already got rid of the old > > > governor convention. They let the user get what they want through > > > simply adjusting the {min,max}_pct (the {min,max}_pct actually limits > > > how the performance is selected). > > > > Adjusting the values individually to me very much looks like the userspace > > governor. > > Yeah, that example was like "userspace". Please take a look at this example: [min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%, then the final target values will not be constant. The ones (65%, 70%, 75%) falling into the limit interval behaves like "ondemand", others are not. > > > > > > I think we can follow the kernel implementation regarding this point, > > > what do you think? > > > > Not sure - I'm not always convinced that what Linux does is the one and only > > and best way. > > Understand it. But I think that usage is good, in terms of supporting future intel processors (e.g. the hardware controlled P-states on Skylake+). The {min,max}_pct needs to be exposed to users to set the limits. How will this affect AMD processors which can use the cpufreq? Would the ondemand feature go away? > > Best, > Wei > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel