ACPI, Power Management Get Big Linux 3.13 Updates

[Pseus]

Hmm, I don't really boot Windows that much, so I don't know whether battery life is different. I get a good 5 hours with light use and WiFi on (low brightness, browsing or coding in a text editor). Used to be around 6 hours when the battery was new. Compiling, or keeping a big IDE with background compiling, static analyzers and auto-complete reduces this a lot (lot's of I/O). I use powertop to check everything is set correctly. Idling with the screen on, wifi on and the disk spinning uses around 9W, which I think is fairly reasonable. I don't know about the newer sleep states. Maybe someone from the Intel team could answer that in their mailing list.

[jrch2k8]

well a bit in linux and other unixes defense there is a big factor that can punish battery in a system and that is multi threading, a thing that is hugely missing in windows apps and OS X apps. AKA linux try to keep all cores feed all the time but OS X GCS[battery] try to keep always all threads in 1 core since most apps are rarely threaded except things like iMovie and well in the case of windows most apps never scale beyond 1 main thread but in linux world threads are used everywhere hence cores have it harder to get into deep states so easily.

[linuxforall]

Intel pstate doesn't make much difference in battery life as I have had the chance to compare a brand new kernel 3.12 Manjaro with Ubutnu 13.10 which comes with kernel 3.11 with pstate disabled. What it does is use CPU far more efficiently when under high load, the CPU scales up quicker with the multi cores so there is overall less heat build up unlike cpu-freq. However at idle the cpu-freq runs the CPUs cooler, at least in case of my Haskel and IVB laptops but the temp shoots up high once there is load and tends to stay there longer as compared to Pstate where temps rise less higher and comes down quicker. The thermal factor can be used to denote the power efficiency of Pstate.
With Kernel 3.9+ I have noticed I get more or less same duration with Windows and Linux running on same hardware.

[liam]

Intel pstate doesn't make much difference in battery life as I have had the chance to compare a brand new kernel 3.12 Manjaro with Ubutnu 13.10 which comes with kernel 3.11 with pstate disabled. What it does is use CPU far more efficiently when under high load, the CPU scales up quicker with the multi cores so there is overall less heat build up unlike cpu-freq. However at idle the cpu-freq runs the CPUs cooler, at least in case of my Haskel and IVB laptops but the temp shoots up high once there is load and tends to stay there longer as compared to Pstate where temps rise less higher and comes down quicker. The thermal factor can be used to denote the power efficiency of Pstate.
With Kernel 3.9+ I have noticed I get more or less same duration with Windows and Linux running on same hardware.

Are you comparing cpufreq and pstate by using two different distros on two different laptops (with different hardware)?
If you want to do a real test run this (through a live usb) on the a single laptop:

https://fedoraproject.org/wiki/Test_Day:2013-11-14_Power_management

Make sure to disable the pstate driver on one of the above runs.
The problem with the above test is that it doesn't make much use of the cpu, it's mostly interested in idle states (which is really important as the pstate driver should be better about staying in lower power states for longer) and autotweaking settings using tuned.
To run a standard load you could stay in the above environment you can download pts.
If you want to just use a single environment apparently pts has a distro you can download (which I wouldn't since it looks to be three years old) and then you can run this module (http://openbenchmarking.org/test/pts...ry-power-usage). I would just download and run pts from the live usb environs above.

[linuxforall]

I have compared it via different distros and also with pstate enabled in kernel via grub entry. In both cases the results paralleled my experience. Idle temps go up on pstate to almost three degrees on average compared to cpu-freq but under load temps and cooling down of CPU under heavy load is faster with pstate than with cpu-freq. Add in the thermal daemon from Intel and combined with pstate, even under heaviest load, temps are controlled and the system never ever throttles. Its a different scenario with cpu-freq where system would throttle heavily under extended load.

The problem with stock Ubuntu kernel is that its not the latest but their own with patches applied whereas in Manjaro I get to use the latest untouched one. I will test Ubuntu with their mainline kernels for a even test.

liam, whats your experience here with pstate and pstate disabled kernel?

[liam]

I have compared it via different distros and also with pstate enabled in kernel via grub entry. In both cases the results paralleled my experience. Idle temps go up on pstate to almost three degrees on average compared to cpu-freq but under load temps and cooling down of CPU under heavy load is faster with pstate than with cpu-freq. Add in the thermal daemon from Intel and combined with pstate, even under heaviest load, temps are controlled and the system never ever throttles. Its a different scenario with cpu-freq where system would throttle heavily under extended load.

The problem with stock Ubuntu kernel is that its not the latest but their own with patches applied whereas in Manjaro I get to use the latest untouched one. I will test Ubuntu with their mainline kernels for a even test.

liam, whats your experience here with pstate and pstate disabled kernel?

I guess I want to live, vicariously, through you since I don't have a system that is supported by the pstate driver (rockin' a t7500 here!) I really thought haswell was gonna be the chip to buy but I was disappointed with the gpu performance for all but the iris pro (and good luck finding one of those), so know I'm waiting on Broadwell, I suppose.
Idle temps shouldn't go up with pstate. You might want to file a bug upstream. While its dynamic aspects should, and apparently are, better, its idle state should also be at least as good as with the generic governor. If it isn't then that's a regression.

[linuxforall]

I guess I want to live, vicariously, through you since I don't have a system that is supported by the pstate driver (rockin' a t7500 here!) I really thought haswell was gonna be the chip to buy but I was disappointed with the gpu performance for all but the iris pro (and good luck finding one of those), so know I'm waiting on Broadwell, I suppose.
Idle temps shouldn't go up with pstate. You might want to file a bug upstream. While its dynamic aspects should, and apparently are, better, its idle state should also be at least as good as with the generic governor. If it isn't then that's a regression.

The idle is high because unlike cpu-freq with ondemand, one of the cores run at relative higher frequencies to keep the CPU in ready state while the other cores are put in deep sleep C states. I talked with Arjan about this so the idle temp rise is a minor issue compared to the efficiency one gets from Pstate and the rapid cooling down unlike in cpu-freq.

The pstate revolution is happening but I am also anxious to see AMD's reply to this.

[liam]

The idle is high because unlike cpu-freq with ondemand, one of the cores run at relative higher frequencies to keep the CPU in ready state while the other cores are put in deep sleep C states. I talked with Arjan about this so the idle temp rise is a minor issue compared to the efficiency one gets from Pstate and the rapid cooling down unlike in cpu-freq.

The pstate revolution is happening but I am also anxious to see AMD's reply to this.

The problem, though, is that heat is directly related to energy used (assuming efficiency is pretty constant, which I thought we could assume...but maybe not). If you keep one core idling higher and the rest power-planed you may not see any advantages especially in long running tasks and if you have to increase the voltage (which you do) to reach the higher clocks. It's good that they recognize the problem but it needs to be fixed as that is still a regression and for most of us, we keep our pcs in idle most of the time, so idle state it incredibly important (likewise for servers).

[linuxforall]

The problem, though, is that heat is directly related to energy used (assuming efficiency is pretty constant, which I thought we could assume...but maybe not). If you keep one core idling higher and the rest power-planed you may not see any advantages especially in long running tasks and if you have to increase the voltage (which you do) to reach the higher clocks. It's good that they recognize the problem but it needs to be fixed as that is still a regression and for most of us, we keep our pcs in idle most of the time, so idle state it incredibly important (likewise for servers).

Good pint thats why the power savings nor the full load performance have any noticeable effect yet as shown by the Phoronix benchmarks but my big lure for pstate is that the Thermal Daemon gets to control CPU temp under load in a far superior fashion.

[liam]

Good pint thats why the power savings nor the full load performance have any noticeable effect yet as shown by the Phoronix benchmarks but my big lure for pstate is that the Thermal Daemon gets to control CPU temp under load in a far superior fashion.

Sure, I get that. I just hope they work on it to get better idle state.