Re: [PATCH 6/6] cpufreq: Evaluate P1 before enter turbo mode

[Dominik Brodowski]

Hey,

On Thu, Dec 23, 2010 at 10:13:54AM -0800, Venkatesh Pallipadi wrote:
> On Thu, Dec 23, 2010 at 6:38 AM, Matthew Garrett <mjg@xxxxxxxxxx> wrote:
> > On Thu, Dec 23, 2010 at 11:57:30AM +0100, Dominik Brodowski wrote:
> >
> >> NACK. First of all, why is it only a "turbo mode" if it's 1000 kHz
> >> difference?
> >
> > I believe that that's how it's supposed to be defined for Intel systems,
> > but you're right that this doesn't belong in generic code. AMD have
> > support for enabling/disabling their equivalent functionality through
> > sysfs - I'd say that copying that interface and using it to limit the
> > set of p-states provided to the core makes more sense.
> >
> 
> If this 1000kHz hack is needed, it should be in acpi-cpufreq driver
> along with Intel CPU and Turbo mode capability check..
> I had a change earlier and I don't think I ever pushed it out. But, it
> was doing the max freq transition on turbo capable CPUs in 2 steps.
> Something like:
> - cpu is in one of the low freqs.
> - ondemand asks for highest freq.
> - acpi-cpufreq will check whether the CPU is turbo capable and will
> only switch to non-turbo peak freq as first step.
> - If ondemand asks for highest freq again, acpi-cpufreq will then
> switch to turbo freq.
> 
> Something like that would probably help the problem here?

then we'd put policy in two places, instead of letting the decision be made
at one place. So I'd not favour such an approach... What should indeed be in
acpi-cpufreq is to mark certain frequency steps as being not power
efficient, though.

Best,
	Dominik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/