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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.15 at 16:56, <wei.w.wang@xxxxxxxxx> 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%?

> 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.

> 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.

Jan


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