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