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

["Wang, Wei W" <wei.w.wang@xxxxxxxxx>]

On 24/04/2015 23:54, Jan Beulich wrote
> >>> On 24.04.15 at 17:42, <wei.w.wang@xxxxxxxxx> wrote:
> > On 24/04/2015 23:04, Jan Beulich wrote
> >> >>> 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%?
> >
> > The {min,max}_pct is a limit.
> 
> That's clear. The question is whether these are hardware imposed limits or
> set by the user. In the latter case ...


The hardware CPU has its own minimal performance limit, let's call it 
hw_min_pct. For example, on my machine, the hw_min_cpt=32% (corresponds to 
1.2GHZ, which is the minimal frequency). 
The [min,max]_pct in our discussion is set by the user via xenpm. If min_pct is 
set to a value less than 32%, than it will be adjusted to hw_min_cpt.
 

> >> > 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 45%, 55%, and 90% here shouldn't happen in any case)

Yes. The final values will be 60%, 60%, 65%, 70%, 75%, 80%. This is neither a 
"userspace" governor nor a "ondemand" governor.


> > The ones (65%, 70%, 75%)
> > falling into the limit interval behaves like "ondemand", others are not.
> 
> ... restricting to these would be the job of the driver, and
> - ondemand would be 0...100
> - powersave would be 0
> - performance would be 100
> Everything else would be userspace.

Please see the example above, the internal governor in the new driver is 
different from these conventional governors.

Best,
Wei

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