Re: powersave governor runs programs faster and uses more power than performance governor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/29/2013 09:27 AM, Melanie Kambadur wrote:
Apologies, I accidentally sent my last mail before finishing...

The available governors I have now are:
conservative ondemand userspace powersave performance.


Only ondemand will have any active control of the P state requested.

performance == highest P state (reported by ACPI) is requested
powersave   == lowest P state (reported by ACPI) is requested
userspace   == Allows the user select a single P state.

With intel_pstate enabled
performance == highest P state (enumerated form CPU) is requested.
powersave   == Active control of the P state similar to ondemand.

To get userspace governor behavior set
/sys/devices/system/cpu/intel_pstate/{min, max}_perf_pct to the same
values.

/sys/devices/system/cpu/intel_pstate/no_turbo allows you to configure
whether P states in the turbo range for your CPU will be selected.


Thankfully, I did not have to modify my kernel at all to get these.
Once I get the chance to run some tests, I will keep you posted as to
whether the governors behave as documented with this new
configuration.

Thanks again for the pointers and suggestions that got me this far!

Melanie

On Tue, Oct 29, 2013 at 12:25 PM, Melanie Kambadur
<melanie@xxxxxxxxxxxxxxx> wrote:
After getting the chance to modify the BIOS, it finally looks like I
have the options that I want in terms of drivers/governors.

FYI, rmmod intel-pstate did not work (before or after modifying the
bios),

intel_pstate is built-in only and not a module :-)

and as I mentioned earlier, before updating the bios, setting
intel_pstate=disable erased most of my driver/governor options.

The cpufreq core creates the sysfs files as governors are registered
with the core.  With intel_pstate=disable the driver will not register
with the core so if no other drivers/governors register with the core
the sysfs files will be missing.

What
did work was to update the BIOS to OS control as suggested, and THEN
setting intel_pstate=disable gave me the acpi-cpufreq driver, along
with the following governors:

On Fri, Oct 25, 2013 at 2:27 PM, David C Niemi <dniemi@xxxxxxxxxxxx> wrote:

I'm pretty sure that Dell's Active Power Controller would supersede what the intel-pstate driver/governor is trying to do as well.  I doubt you will have enough control over the box to do meaningful tests until you can get the BIOS power setting changed to "OS Control".

speedstep and p4-clockmod are both ancient.  But it is all moot if the BIOS won't let the OS manage the CPU.

It is possible your distribution is a bit too stripped down.  You might want to build and install your own kernel so you can make sure all the sensible options are in it.  But it is also possible acpi-cpufreq is built in so you don't see it as a module, and it is not possible to activate it due to the Active Power Controller getting in the way.

Meanwhile, can you rmmod intel-pstate?

DCN

On 10/25/13 12:35, Melanie Kambadur wrote:
If I disable intel_pstate on my kernel command line, I end up with
access only to the speedstep and p4-clockmod drivers, and no
acpi-cpufreq driver.  Is there a way to download the acpi-cpufreq
driver? I've tried a couple of things without success.

BTW, I haven't gotten the chance to modify the BIOS yet (waiting on a
sysadmin).
-Melanie

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux