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

Best,
Wei


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