Re: [PATCH V6 1/3] cpufreq: intel_pstate: configurable algorithm to get target pstate

[Thomas Renninger <trenn@suse.de>]

On Tuesday, December 08, 2015 10:02:23 AM Srinivas Pandruvada wrote:
> On Tue, 2015-12-08 at 16:27 +0100, Thomas Renninger wrote:
> > Hi,

> > There may be atoms clustered in server platforms and there may be
> > performance oriented CPU models built into laptops.
> 
> You mean BYT/CHT ATOM used as servers not Avaton, which has different
> id.

I have no idea.
And since Intel does not build mainboards anymore afaik or most
are built by OEMs, you also have no idea which CPUs end up on which kind
of system, right?

Default policy to go for performance, IO, workload based switching or
whatever tunables are modified should be, as you said, platform oriented.

So instead of calling the params:
silvermont, airmont, knl_params (knights landing, right?), whatever CPU...
Better call them:
laptop, io_optimized, performance params, whatever ...
And later set them according to pm_profile, not CPU id and still
provide something to override via userspace (I hope this is
what you want to do anyway, right?).
Even someone buys a tablet, there are Linux guys around who use them as
their homeserver in 2 years and they want to override...

Hm, in fact what you are doing is you implement your own governors/policies 
inside intel_pstate driver now, right?
If not done already, you should name it in dmesg what kind of algorithm is 
used (cmp with my patch). This makes it easier to find powersave
or performance regressions that will come up with the new default settings
and pin point them to intel_pstate.

Even better would be if intel_pstate could set it's own governor string.
Then there wouldn't be any mixture with ondemand or whatever.
But again.., those should not be named "airmont" policy/governor.

I had a quick look, but providing whole governors seem to be a lot overhead.
But with some luck you do not have to fill up whole structures you have to
pass to cpufreq_register_governor(..).

        Thomas