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
cpuinfo_*. The documentation is normally distributed with kernel source packages. Specifically, I recommend reading
<kernel-sources-dir> would typically stand for
/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
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
- result of a bug in
cpufreq implementation for your CPU (or entire family),
- specific to the implementation of
performance CPU governor as of
Some of the things you might do to push your investigation further:
- read the
user-guide.txt and fiddle more with other
- 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.