[CentOS] Questions on cpu frequency scaling AMD vs. Intel
maillists at conactive.com
Mon Aug 4 09:08:55 UTC 2008
S.Tindall wrote on Sun, 3 Aug 2008 21:47:06 -0400:
> The cpuspeed changelog may be relevant:
> * Thu Mar 06 2008 Jarod Wilson <jwilson at redhat.com>
> - Disable freq scaling by default on AMD rev F and earlier cpus
> when running xen, due to clock instability (#435321)
Thanks, it didn't occur to me that cpuspeed may also be relevant to this.
However, I don't think it's relevant for the wrong cpu frequency reading
on the 3.2 Xen kernels (which in turn is responsible for the missing
scalability). Cpuspeed is not part of the kernel and did not change during
all my tests. See below for possible explanation.
> I didn't look up your cpu, but I think it's a revision F.
Hm, /proc/cpuinfo doesn't show any revision number. A bit googling tells
me that the CPUs, at least the second one, are more likely to be rev. H or
above. The older one is a 3800+ EE and the newer one is a 4850e which I
bought right after it became available. Unless rev. G and up are only quad
core CPUs at least the latter 45nm one should be rev G or up, too. But I
can't find a definitive list, shouldn't there be one on the AMD site?
I saw postings about time problems on the xen-devel list, but these seemed
to be more general and not restricted to older revisions of the AMD cpus.
Now, after enabling frequency scaling on both I see that as well ("Warning
Timer ISR/1: Time went backwards:"), but only on the newer CPU. It happens
each time the frequency changes. It's possible it doesn't happen on the
other (older!) cpu because there wasn't demand for a change yet, it's not
doing any cpu intensive tasks.
> Also, thanks for the /etc/sysconfig/cpuspeed "ondemand" tip.
> It seemed counterintuitive to explicitly specify the so-called
> default governor value (i.e., "empty defaults to ondemand"),
> but doing so did the trick under xen for my
> revision G AMD processor.
I think what happens with cpuspeed is that the "Thu Mar 06 2008" patch
mentioned above comes into play here. I assume they simply do not modprobe
cpufreq_ondemand and thus it is not available and cannot be used as a
default. All the other governors are available, no matter if cpuspeed is
running or not, and ondemand is the only one that does real scaling. So,
they simply disabled this and it gets only loaded once you force it (good,
that they didn't disable that either).
ondemand is missing on *both* kernels (the 3.2 one from Xen and the stock
CentOS kernel) by default and adding the commandline I mentioned doesn't
change this. However, it makes a difference on the Xen 3.2 (and Xen 3.2.1)
kernel, as it corrects the frequency reading.
The time warning only seems to occur on the Xen 3.2 kernels and not on the
CentOS Xen kernels. At least I don't remember having it seen earlier.
Which Xen kernel are you running?
Hm, it occurs to me now that the older cpu where the time warning doesn't
appear runs already on Xen 3.2.1 which may already have some patch to
avoid this bug. Or it simply doesn't report it anymore :-) (It doesn't
seem to be of any harm, not even dovecot - which is paranoid about time
and has it's own time warning routinge - barks. But it spoils my
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
More information about the CentOS