[CentOS] Questions on cpu frequency scaling AMD vs. Intel

[Kai Schaetzl]

S.Tindall wrote on Sun, 3 Aug 2008 21:47:06 -0400:

> The cpuspeed changelog may be relevant:
> 
> [quote]
> * 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)
> [/quote]

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 
monitoring :-()

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com