[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/9] Porting the intel_pstate driver to Xen



On 23/04/2015 22:09, Jan Beulich wrote:
> >>> On 23.04.16 at 15:31, <wei.w.wang@xxxxxxxxx> wrote:
> > The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all
> > the logic for selecting the current P-state. It follows its
> > implementation in the kernel. Instead of using the traditional cpufreq
> > governors, intel_pstate implements its internal governor in the
> > "setpolicy()".
> 
> And this internal governor behaves how? Like ondemand, powersave,
> peerformance, or yet something else? And how would its behavior be
> changed?
> 
> Jan

Hi Jan,

In the kenel intel_pstate implementation, they have two internal governors: 
Powersave and Performance.
Powersave is similar to the old (cpufreq) ondemand governor. A timer function 
is periodically invoked to sample the CPU busy info (e.g. will get increased 
due to the running of a CPU-intensive workload). However, the final calculated 
target value is clamped into the [min_pct, max_pct] limit interval.
The Performance governor is actually a special case of Powersave, when the 
min_pct= max_pct=100%. This is the same as the old performance governor.

Here in the ported version, the limit interval can be set via the new added 
interfaces in xenpm. I think we can make use of only the Powersave governor, 
and the Performance governor can actually be simply achieved by setting 
min_pct= max_pct=100%. 

If all of you are agree, I will remove the Performance governor related code in 
the next version of patchset.  

Best,
Wei

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.