Monday, 2 July 2012

What's eating my CPU frequency?

I noticed that after sequentially unplugging my laptop, suspending, connecting it to the AC and resuming, computationally intensive applications suddenly were a lot slower. Today I finally investigated this conundrum.

First I looked around in /sys/devices/system/cpu/cpu?/cpufreq/. The file scaling governor told me my CPU frequency was regulated by in userspace. The current frequency was 1.3 GHz according to scaling_cur_freq. My CPU is an Intel Core i7-2670QM running at 2.2 GHz (3.1 GHz in Turbo Mode) so it was running way too slow. By fiddling with scaling_setspeed and scaling_governor I could put the processor speeds back to normal and restore the performance. A simpler solution was to unplug the AC adapter and plug it back in. Presumably, fires an (ACPI?) event which some system regulating my CPU missed when my laptop was suspended.

Manually fiddling with these files got tiresome so I installed sys-power/cpufrequtils and app-benchmarks/i7z to lighten this workload.

I wanted to find the application that was responsible for tinkering with my CPU without my permission, so I used the inotify framework. I wasn't sure this would work on a sysfs file system but I did get results. Yet they were not what I expected. Apparently something wrote a "1" or "0" to /sys/devices/system/cpu/sched_smt_power_savings which is a scheduler option to determine whether or not to distribute load over different cores in the CPU. No application altered the frequencies or it had to remain unnoticeable to inotify. I tried using the audit framework of the Linux kernel to investigate further but it triggered kernel oopses and I didn't feel like solving that problem too.

The sched_smt_power_savings file turned out to be a dead end. Although inotify doesn't give you the PID of the offending process, it wasn't hard to find it in the folder which contains the source code for all installed programs. Thanks to my powerful CPU and a Corsair Performance Pro 256GB SSD, it only took about 10 seconds to zgrep the entire 2.9 GB folder. This pointed me towards sys-power/pm-utils which as it turned out had nothing to do with it.

I still suspected some part of the awfully unconfigureable GNOME 3 to be responsible so I tried shutting it down, with no effect on the behaviour of my CPU. Shutting down service after service nothing changed. In the end the only processes running on my computer were init and some fish shells. Still the CPU frequency dropped by 40% if I unplugged the computer. I'm assuming this means either this is because of a really stupid kernel default in the ACPI subsystem, or some service uploads a stupid power saving scheme to the kernel before it gets destroyed. Per chance this might even be built in the chipset of this laptop.

This isn't the end of this story...

No comments:

Post a Comment