# warning: cpufreqd and 3.8.x kernels

## khayyam

greets ...

I had noticed that sometime during 3.7.x => 3.8.x my load average was greatly increased, nothing obvious seemed to be the cause and so I put it down to a regression of the 3.4 bug. However, by 3.8.8 it was beginning to annoy me, as the load average would be at 0.{70,80,90} when the machine was completely idle. At this time I also noticed the following in dmesg:

```
ACPI: EC: GPE storm detected(13 GPEs), transactions will use polling mode
```

So, after disabling anything that may be polling ACPI, by a process of elimination I was able to place the blame on cpufreqd. Having disabled it load average was back to normal, and no more GPE storms.

A little research suggests that cpufreqd/cpufrequtils are out of step with kernel changes to sysfs, and so cpufreqd is probably polling aggressively trying to make sense of these changes. It also seems that cpufreqd/cpufrequtils are reaching end of life, or at least no-longer maintained, or have been replaced with sys-power/cpupower (the very minimal information available suggested one or other of the above).

Having come across sys-power/cpupower I thought I'd give it a try, it is still ~arch but ssuominen has a bug open with the intent of getting it ready as a possible replacement for cpufreqd/cpufrequtils. If your having similar issue to those above I'd suggest you take a look at cpupower. Note that with /etc/conf.d/cpupower similar options can be passed as were provided by /etc/conf.d/cpufrequtils, mine currently looks like the following:

```
# /etc/conf.d/cpupower: config file for /etc/init.d/cpupower

# Options when starting cpufreq (given to the `cpupower` program)

START_OPTS="--governor ondemand"

# Options when stopping cpufreq (given to the `cpupower` program)

STOP_OPTS="--governor performance"

# Extra settings to write to sysfs cpufreq values.

#

# up_threshold: threshold for stepping up frequency, where the value represents

# the percentage of cpu load.

# 

# down_threshold: threshold for stepping down frequency, where the value

# represents the percentage of cpu load.

#

# sampling_down_factor: determines how frequently the governor polls the cpu, a

# value greater than 1 improves performance by reducing the polling when the

# load is high. This tunable has no effect on behavior at lower CPU frequencies

#

# ignore_nice_load: when set to '1' the processes that are run with a 'nice'

# value will not count in the usage calculation.

SYSFS_EXTRA="ondemand/ignore_nice_load=1 ondemand/up_threshold=11 ondemand/sampling_down_factor=10" 
```

I haven't really spent much time looking at what features are available, 'monitor' looks interesting, but I'm not sure what it does exactly, eventually I'll integrate various things into /etc/acpi/default.sh, and so the need for a daemon isn't so pressing.

best ... khay

----------

## Maitreya

Does powertop give any info on the cause of this load?

----------

## khayyam

 *Maitreya wrote:*   

> Does powertop give any info on the cause of this load?

 

Maitreya ... the cause was cpufreqd as I wrote above ... so, this is not a call for assistance, but a warning to others who may encounter the same issue.

best ... khay

----------

## Maitreya

I'm sorry I did not mean to offend. Tried replicating the issue with kernel 3.8.8 and cpufreqd but can not get the same results.

I just like to get to the bottom of a problem to offer multiple solutions to a problem.

----------

## khayyam

 *Maitreya wrote:*   

> I'm sorry I did not mean to offend. Tried replicating the issue with kernel 3.8.8 and cpufreqd but can not get the same results.

 

Maitreya ... no offence read, or taken. Interesting that its not reproducable your end, what version of cpufreqd?

My battery (and/or perhaps ACPI) is somewhat odd in that it shows a full charge but the machine will die at 74% discharge if running off it, perhaps this has something to do with it, acpid doesn't seem to have any issues in that regard, and given that everything reported above has stopped since cpufreqd was removed I can only think its a bug of some sort.

best ... khay

----------

## Maitreya

I'm sorry I have the bad habit of reading the wrong things online (irl just a bit less bad)

I am using sys-kernel/geek-sources-3.8.8 and sys-power/cpufreqd-2.4.2 together.

Really curious about the GPE storm origin and effect. Does the battery show other charge amount in other kernels/os?

Making a big guess here : What if the GPE's cause the cpufreqd to constantly change frequences and this in turn would cause the load.

----------

## khayyam

 *Maitreya wrote:*   

> I am using sys-kernel/geek-sources-3.8.8 and sys-power/cpufreqd-2.4.2 together.

 

Maitreya ... likewise the same, and geek-sources has bfq, branding, ck, deblob, genpatches, and ice useflags enabled

 *Maitreya wrote:*   

> Really curious about the GPE storm origin and effect. Does the battery show other charge amount in other kernels/os?

 

I don't actually think the battery is at issue, it has really never been used (in part due to the above), I think its an firmware/ACPI issue, but its the same problem regardless of kernel/OS (though I have to admit its been some years since any other OS was booted). The EC is I belive related to the battery, and why the storm occurs I can only guess, I assume as cpufreqd doesn't know if we are on AC or battery or something of that nature, as I said nothing else seems to have an issue in that regard. 

 *Maitreya wrote:*   

> Making a big guess here : What if the GPE's cause the cpufreqd to constantly change frequences and this in turn would cause the load.

 

The GPE storm only happens with 3.8.8, before that it was just the load, I did once catch cpufreqd spiking the CPU but just assumed that this was perhaps a frequency change as I'd been compiling something prior. The load never cause any kind of frequency change, or a lag of any kind as it would be bellow 0.90 ... but something wasn't right considering that the load would be at 0.70 or so when the machine was essentially idle.

best ... khay

----------

## ulenrich

@khayyam,

coming up Linux-3.9 again has new infrastructure, I have seen:

# CONFIG_SENSORS_ACPI_POWER is not set

# CONFIG_SENSORS_ATK0110 is not set

CONFIG_THERMAL=y

CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y

# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set

# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set

CONFIG_FAIR_SHARE=y

CONFIG_STEP_WISE=y

# CONFIG_USER_SPACE is not set

CONFIG_CPU_THERMAL=y

which should have some impact on performance. And some advantages for mobile users. I am not yet into it - it seems to me complex ....

----------

## khayyam

ulenrich ... all of these options are also in 3.8.x though the defconfig may differ (if the above is defconfig). I was thinking that it was maybe the introduction of THERMAL_DEFAULT_GOV_STEP_WISE=y that was effecting cpufreqd but the issues go back prior to that, so, unlikely.

Some of the above already exist as ACPI drivers (CPU_THERMAL for instance has ACPI_PROCESSOR so the former seems to be a generic driver for where the acpi driver is unsuported), and some is explictly ACPI 4 (SENSORS_ACPI_POWER) and/or hardware specific (SENSORS_ATK0110).

Not sure how any of this is relevant but thanks ... khay

----------

