RE: [patch 2/2] x86: Manage ENERGY_PERF_BIAS based on cpufreqgovernor - v2

From: Pallipadi, Venkatesh
Date: Thu Mar 04 2010 - 18:34:19 EST

>-----Original Message-----
>From: Dave Jones [mailto:davej@xxxxxxxxxx]
>Sent: Thursday, March 04, 2010 3:28 PM
>To: Pallipadi, Venkatesh
>Cc: Ingo Molnar; H Peter Anvin; Thomas Gleixner; Len Brown;
>linux-kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx;
>Venkatesh Pallipadi
>Subject: Re: [patch 2/2] x86: Manage ENERGY_PERF_BIAS based on
>cpufreq governor - v2
>On Thu, Mar 04, 2010 at 03:14:56PM -0800, Venki Pallipadi wrote:
> > + if (!strncmp(gov->name, "performance", strlen("performance")))
> > + epb_val = ENERGY_PERF_BIAS_PERF;
> > + else if (!strncmp(gov->name, "powersave", strlen("powersave")))
> > + epb_val = ENERGY_PERF_BIAS_POWER;
> > + else
> > +
> > + set_epb_on_cpu(epb_val, cpu);
> > + return 0;
>hardcoding a list of cpufreq governors is kinda icky, but I don't have
>a better solution. We'll just have to be mindful of it if we ever
>get around to finally making performance/powersave personalities
>of ondemand as was discussed years ago.

Yes. In that case we will have to find some other way to tie this to
user preference.

>What if the governor is set to 'userspace' ?
>powernowd/cpufreqd are sort of ondemand-done-in-userspace, but there
>may also be other userspace governors we don't know about.
>I suppose it's not catastrophic..

Userspace/ondemand/conservative can all be at middle ground here as
they are mostly used where user expects adaptive kind of behaviour.

I did think about exporting this as a new tunable in /sys and let
userspace deal with it. But, that doesn't help with having sane default
values and users (background apps) may shoot themselves in the foot
with it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at