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

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

On 24/04/2015 20:57, Jan Beulich wrote
> >>> On 24.04.15 at 13:53, <wei.w.wang@xxxxxxxxx> wrote:
> > On 24/04/2015 18:20, Jan Beulich wrote
> >> >>> On 24.04.15 at 12:07, <wei.w.wang@xxxxxxxxx> wrote:
> >> > On 24/04/2015 17:56, Jan Beulich wrote:
> >> >> >>> On 24.04.15 at 11:46, <wei.w.wang@xxxxxxxxx> wrote:
> >> >> > On 24/04/2015 17:11, Jan Beulich wrote:
> >> >> >> >>> On 24.04.15 at 10:32, <wei.w.wang@xxxxxxxxx> wrote:
> >> >> >> I think at the very least from a user interface perspective (e.g.
> >> >> >> the xenpm
> >> >> >> tool) the meaning of the old governor names should be retained
> >> >> >> as much as possible.
> >> >> >
> >> >> > Ok. I am simply using the name "internal" for user tools. Please
> >> >> > see the example below:
> >> >> >
> >> >> > scaling_driver           : intel_pstate
> >> >> > scaling_avail_gov    : internal
> >> >> > current_governor    : internal
> >> >>
> >> >> But xenpm's set-scaling-governor command should still do something
> >> >> useful for the currently available governor options. And with
> >> >> that, showing "internal" in its output may also end up being
> >> >> confusing (at least I am already being confused).
> >> >
> >> > The case is similar to that in the kernel. Xen has two pstate
> >> > driver, but only one can be loaded. When the intel_pstate driver is
> >> > used
> >> ("scaling_driver
> >> >  : intel_pstate "),   xenpm's set-scaling-governor will not take effect,
> > since
> >> > the intel_pstate only implements its internal governor.
> >>
> >> But that's precisely what I'm asking to be changed: Even if
> >> internally is
> > uses
> >> its own governor, the user interface of the tool should still be
> >> usable to achieve similar effects.
> >
> > Yes, we should change that if we remain two governors in the
> > intel_pstate driver.
> > But as we discussed before, the internal Performance governor seems
> > redundant and can be removed. In that case, there is no other option
> > of governors that be selected by the user via set-scaling-governor.
> 
> 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%. 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).

I think we can follow the kernel implementation regarding this point, what do 
you think?  

Best,
Wei
 



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