You are not logged in.
Interesting note, especially useful for anyne who keeps the wiki up to date (specifically CPU Frequency Scaling) and the Devs for what governor they should enable by default...
It doesn't matter how much training you have. A broken rib is still a broken rib.
Offline
edit: thanks
Last edited by sl1pkn07 (2013-05-17 16:47:22)
Offline
Offline
I suppose the "new" part is related to the kernel option "CONFIG_X86_INTEL_PSTATE" .
The new code in the 3.9 kernel, under, CONFIG_X86_INTEL_PSTATE, is a fresh approach to all of this.
First of all, we use the enumeration of the hardware capabilities that Intel processors provide, which means we're not limited by what ACPI can express (ACPI is a bit too limiting on anything modern).
We also, and I realize this might be controversial, combine the control algorithm with the cpu driver in one. The reality is that such control algorithms are CPU specific, the notion of a generic "for all cpus" governors is just outright flawed; hardware behavior is key to the algorithm in the first place....The algorithm also, and we'll be tuning this for a while still, much more in line with modern hardware behavior.... we are seeing very significant power/performance improvements with the 3.9/3.10rc code over using ondemand, and a much smaller performance gap with the "performance" governor in terms of performance.
the 3.9/3.10-rc1 code right now only supports SNB cpus, but the CPU ID of IVB is about to added as well.
Offline
Just installed thermald-git from aur which should implement Intels "new" methods of powersaving for my snb-cpu. So far its just an impression but power usage (as measured by powertop) is 2 W less then before during idle.
Offline
There is some potential for confusion from the pstate governors' naming: the "powersave" governor seems to be the "new" cpufreq_ondemand, at least it does not behave like cpufreq_powersave (which runs the cpu at the minimum frequency).
@tobsen:
if you run the stock arch kernel on snb and haven't changed any settings regarding the governor, you get "powersave" by default.
Last edited by hokasch (2013-05-17 19:03:10)
Offline
Nice discussion in the g+ link; thanks to the op for posting. Trying Ted's patch to enable ivybridge support now.
EDIT: Booted into the kernel just fine and pstates is active on my i7-3770k. Since this is a desktop, powertop will not track my power consumption. Can't say I feel a difference
% cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate
Last edited by graysky (2013-05-17 19:22:20)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
This isn't anything new -- Intel has been talking about the "race to idle" for years.
This isn't about Race To Idle. This is about scrapping cpufreq / cpupowered at the kernel level and replacing it with proper CPU drivers. It really doesn't make much sense to have a governor (*looks at OnDemand*) that is supposed to be all about staying idle, have to continually wake up the CPU FROM idle to do its job.
It doesn't matter how much training you have. A broken rib is still a broken rib.
Offline
To anyone who's installed the Thermald package from the AUR, I (geric) added a small comment to the package. The package A) Needs a maintainer (currently orphaned) B) It also requires the package "msr-tools" from the AUR and requires that the module "msr" be auto-loaded on boot to fully function. Just an FYI
It doesn't matter how much training you have. A broken rib is still a broken rib.
Offline
Just installed thermald-git from aur which should implement Intels "new" methods of powersaving for my snb-cpu. So far its just an impression but power usage (as measured by powertop) is 2 W less then before during idle.
Just FYI - thermald is not required for the pstates driver.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
When can we expect this in Arch Linux kernel?
Offline
When can we expect this in Arch Linux kernel?
#grep CONFIG_X86_INTEL_PSTATE /var/abs/core/linux/config
CONFIG_X86_INTEL_PSTATE=y
The kernel option is set, if you boot the current kernel on sandybridge you will get the powersave governor (pstates, not cpufreq) by default.
Offline
tobsen wrote:Just installed thermald-git from aur which should implement Intels "new" methods of powersaving for my snb-cpu. So far its just an impression but power usage (as measured by powertop) is 2 W less then before during idle.
Just FYI - thermald is not required for the pstates driver.
True, it just helps. More of a complete power management suite. I know thanks to thermald and the new pstate driver my system is about 10degrees cooler than usual and stays that way even under load.
It doesn't matter how much training you have. A broken rib is still a broken rib.
Offline
Thanks for posting the heads up in the #1 link from me as well. I had trouble with an SNB i3 in the current kernel with "powersave" enabled via tlp (cpupower defaults commented out). The frequency would stick to the lower bounds min_freq. and I was looking into it when I read this.
Turns out not using the tlp options for frequency scaling and setting "performance" in cpupower brings the machine back to normal. Moreover the powerconsumption (believing powertop for now) appears to be back to low levels from 3.7.9. despite the new governor (~10%+ less than with any 3.8 kernel on this machine). Good start, going to be interesting how this develops.
Offline
The kernel option is set, if you boot the current kernel on sandybridge you will get the powersave governor (pstates, not cpufreq) by default.
I have IvyBridge and "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" returns "acpi-cpufreq". ;/
"+Rob Townley If you are running on a Ivy Bridge CPU, you'll need a patch like this (which +Arjan van de Ven mentioned as hopefully getting pushed upstream before 3.10 is released): http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/commit/?h=test-build&id=eb10f71a176396e4a8e2f8edc01b359d8c8e0dc9"
So, for IvyBridge we need to use this patch or it works with Ivy Bridge Out Of The Box?
Offline
...So, for IvyBridge we need to use this patch or it works with Ivy Bridge Out Of The Box?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
ah yes. Thanks :facepalm:
Offline
I also noticed that now with 3.9 /proc/cpuinfo reports the true clock frequency even when overclocked for every core .
Offline
Looks like intel_pstate isn't able to change CPU's frequency (always max, also on powersave) when it's used in combination with CONFIG_NO_HZ_FULL (full tickless) on 3.10 rc2 (patched for ivy).
Can someone confirm?
Offline
just to be sure, since I've seen some contraditory information (although I think it's false). This (both p-states and thermald) will only make a difference in ivy+, right? (I have IronLake)
Offline
just to be sure, since I've seen some contraditory information (although I think it's false). This (both p-states and thermald) will only make a difference in ivy+, right? (I have IronLake)
No. Currently only Sandybridge. But if you use the patch shown in this thread, Sandy + Ivy. Ironlake is the graphics chips... odds are if you're IL you are also Sandy or Ivy.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Ivy Bridge will be supported in the kernel 3.10?
Offline
el mariachi wrote:just to be sure, since I've seen some contraditory information (although I think it's false). This (both p-states and thermald) will only make a difference in ivy+, right? (I have IronLake)
No. Currently only Sandybridge. But if you use the patch shown in this thread, Sandy + Ivy. Ironlake is the graphics chips... odds are if you're IL you are also Sandy or Ivy.
So maybe it's not ironlake? I have a Intel(R) Core(TM)2 Duo CPU T7250 that's Merom? All this naming schemes are just confusing
EDIT: i think I got it... my processor has "Core" architecture, which is way behind anything in this topic. Carry on
Last edited by el mariachi (2013-05-23 19:23:41)
Offline
Ivy Bridge will be supported in the kernel 3.10?
This is covered in the Google+ link above. But I'll tell you what it said. Apparently, the merge window closed before it was felt that IVB had gotten enough testing to add its code into the sources. But since it is a simple one line addition that does nothing more than actually add the IVB code to the list of supported chips, there was hope that it would be allowed to merge after the window was closed. Soooo maybe.
Offline