On 24/04/2015 18:20, Jan Beulich wrote
> >>> On 24.04.15 at 12:07, <wei.w.w...@intel.com> wrote:
> > On 24/04/2015 17:56, Jan Beulich wrote:
> >> >>> On 24.04.15 at 11:46, <wei.w.w...@intel.com> wrote:
> >> > On 24/04/2015 17:11, Jan Beulich wrote:
> >> >> >>> On 24.04.15 at 10:32, <wei.w.w...@intel.com> 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.
Best,
Wei
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
