# Intel_pstate: One Core always 100% C0 state

## sgsdxzy

I am using a laptop with Intel Ivy bridge core i7 3610QM. I updated my kernel to 3.10 and started to use intel_pstate as scaling driver:

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

intel_pstate

However I find that one of my four cores is always in C0 state even when there is no activities. I monitored it using i7z:

Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %   C7 %  Temp

        Core 1 [0]:       3288.24 (32.97x)      99.7       0 0       0       0    83

        Core 2 [1]:       3138.62 (31.47x)         1       0 0       0    99.7    74

        Core 3 [2]:       3175.46 (31.84x)         1    0.891 0       0      99    76

        Core 4 [3]:       3177.34 (31.86x)         1    0.21 0       0    99.3    71

Also cpu frequencies never scale down, resulting in very high temp.

#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

powersave

It does say powersave, and my cpu is capable of 1.20Ghz to 3.30Ghz

I don't know if I misconfigured or misunderstood something. Can someone tell me why?

Thanks!

----------

## eccerr0r

Are you sure you're running nothing? Get out of X completely, etc.

My i7-2700K and i5-3317U do stay out of C0 state on all cores when completely idle...  If you have some quick interrupt handler that doesn't take that much cpu, it could trigger it to stay in C0...

----------

## sysrqalt

Switching Full dynticks system to Idle dynticks system under Timers subsystem in my kernel config fixed both problems for me.

----------

## sgsdxzy

 *eccerr0r wrote:*   

> Are you sure you're running nothing? Get out of X completely, etc.
> 
> My i7-2700K and i5-3317U do stay out of C0 state on all cores when completely idle...  If you have some quick interrupt handler that doesn't take that much cpu, it could trigger it to stay in C0...

 

Yeah, I truned off X and get the same result...

----------

## sgsdxzy

 *sysrqalt wrote:*   

> Switching Full dynticks system to Idle dynticks system under Timers subsystem in my kernel config fixed both problems for me.

 

Thanks, I am using full dynticks too. I will try idle dynticks.Last edited by sgsdxzy on Fri Jul 05, 2013 5:52 am; edited 1 time in total

----------

## sgsdxzy

Switching to Idle dynticks system does fix the problem. But I am still wondering if it was a bug....

----------

## eccerr0r

No, it's not a bug.  That's an interrupt handler and if it keeps on pinging the machine, it can't stay in sleep.

----------

## sgsdxzy

 *eccerr0r wrote:*   

> No, it's not a bug.  That's an interrupt handler and if it keeps on pinging the machine, it can't stay in sleep.

 

I am just wondering if it is taking too much cpu resources, resulting in too high temp, and while full dynticks is designed to save power, using too much energy...

----------

## kernelOfTruth

 *sgsdxzy wrote:*   

>  *eccerr0r wrote:*   No, it's not a bug.  That's an interrupt handler and if it keeps on pinging the machine, it can't stay in sleep. 
> 
> I am just wondering if it is taking too much cpu resources, resulting in too high temp, and while full dynticks is designed to save power, using too much energy...

 

full dynticks in fact does currently eat more energy

I've experienced this first-hand on my laptop where e.g. battery runtime with full dynticks (around 2.5 - 3 hours) went up to 8-9 hours with idle dynticks

it's far from ready to suit its destined purpose yet ...

----------

