Apologies, change in behaviour wasn't 3.14 to 3.16, it was between 3.2
and 3.14.
strace output of cpufreq-set from 3.16 (3.14 shows same behaviour):
8820 open("/sys/devices/system/cpu/cpu0/cpufreq/related_cpus",
O_RDONLY) = 3
8820 read(3, "0\n", 4095) = 2
on 3.2:
2257 open("/sys/devices/system/cpu/cpu0/cpufreq/related_cpus",
O_RDONLY) = 3
2257 read(3, "0 1 2 3 4 5 6 7\n", 4095) = 16
On both kernels the affected_cpus just contains "0" - i.e. that core itself.
The man page for cpufreq-set says:
-r --related
modify all hardware-related CPUs at the same time
So I think it's reasonable from this description to conclude that all
CPUs on the same physical piece of silicon should be configured when
this flag is set (and this is the behaviour as of Wheezy / 3.2).
However the kernel docs at Documentation/cpu-freq/user-guide.txt say:
affected_cpus : List of Online CPUs that require software
coordination of frequency.
related_cpus : List of Online + Offline CPUs that need
software coordination of frequency.
The system seems to function OK with the cores running at different
frequencies, so I suppose the kernel is correct.
So it doesn't really look to me like reading related_cpus is the right
thing for cpufreq-set to do (any more?), because the kernel will already
change all CPUs which require coordination (if you have some CPUs
offline it might even cause cpufreq-set to fail?), and if it wants to
keep the same behaviour as with previous kernels (and also the currently
documented behaviour), then it should instead use the info in:
/sys/bus/cpu/devices/cpu0/topology/core_siblings_list
or
/sys/bus/cpu/devices/cpu*/topology/physical_package_id
(perhaps the latter is just a different expression of the former tho' -
I haven't checked the source...
Cheers,
Tim.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
