Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I see the cores on an Intel i5 machine I'm looking at can only be run at the same clockspeed: /sys/devices/system/cpu/cpu1/cpufreq/related_cpus lists all of the CPUs. Setting cpu1's clockspeed changes cpu0's, as expected.

Supposedly the AMD A6-4400M machine I'm running should be able to run each core at a different clockspeed:/sys/devices/system/cpu/cpu1/cpufreq/related_cpu only lists cpu1. When I set cpu1's clockspeed by using the performance governor and echoing 1400000 to scaling_max_freq, cpu0's clockspeed remains at 2700000 as expected. Cpu1's scaling_cur_freq reads 1400000 as expected.

However, cpu1's cpuinfo_cur_freq reads 2700000. From benchmarking, it appears CPU1 is indeed still running at 2.7 GHz. Am I missing something, or is something broken?

I'm running Linux 2.6.35, and passing idle=mwait in the kernel command line.

share|improve this question
add comment

1 Answer 1

This is not yet close to be a definite answer. Instead, it's a set of suggestions too long to fit in comments.

I'm afraid you might slightly misinterpret the meanings of sysfs cpufreq parameters. For instance, on my Core Duo laptop, the related_cpu parameters for both cores read 0 1 - which, according to your interpretation, would mean that the cores cannot switch frequencies independently. But that is not the case - I can set each frequency at will. By contrast, the affected_cpus parameter for each core lists only the respective CPU number.

You might want to take a look at kernel documentation for cpu-freq to get a better understanding of the parameters such as affected_cpus,related_cpus,scaling_* and cpuinfo_*. The documentation is normally distributed with kernel source packages. Specifically, I recommend reading <kernel-sources-dir>/Documentation/cpu-freq/user-guide.txt, where <kernel-sources-dir> would typically stand for /usr/src/linux or /usr/src/linux-<kernel-version>. (However, when I skim through the documentation myself now, I confess I don't catch some of the frequency-scaling-related nuances. To fully understand these, one probably needs to gain a solid understanding of CPU architectures first.)

Back to your question. And one more test case on my part: when I change the value of scaling_max_freq (with either userspace or performance governor being used), the core's clock automatically switches to that new maximum. The different behaviour you're observing might be any of:

  • specific to hardware implementation of frequency scaling mechanisms on your CPU,
  • due to differences between the standard cpufreq module and phc-intel which I'm using,
  • normal behaviour (call it a bug or a feature if you will) of cpufreq module, which has changed at some point since 2.6.35 (my current kernel version is 3.6.2),
  • result of a bug in cpufreq implementation for your CPU (or entire family),
  • specific to the implementation of performance CPU governor as of 2.6.35.

Some of the things you might do to push your investigation further:

  • read the user-guide.txt and fiddle more with other cpufreq parameters,
  • repeat the tests while running a newer kernel - the easiest way is to boot a liveCD/DVD/USB.

If you continue to experience unexpected behaviour and gain more reasons to believe it is due to a bug (definitely must check with the latest minor kernel version), go ahead and report this on kernel.org bugzilla.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.