RE: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

> > It made no discernable difference in my tests.  I did high to low
> > and low to high changes roughly every five minutes, and always got
> > an excessive difference inside of Xen and usually got error messages
> > in Linux.
> 
> It's a bit confusing as to what is going on since there are 4 
> CPUs in the system.

It's two dual-core processors.  Each dual core processor
shares frequency and voltage for both cores, so only
two transitions are being sent to Xen.

> Are arbitrary or all CPUs changing frequency, or just 
> one of them?

All processors are changing frequency.  There's probably
a delay in the command that changes the frequency, so cores 0,1
go at the same time, then 2,3 slightly later.

> Is the single-step PSTATE_CTRL MSR being used, or the 
> multi-step FID_VID method where voltage adjustments
> are under software control? 

Multistep.  Processors with single step also have pstate
invariant TSCs and don't seem to run into this issue.

> It'd be useful to have each tracing line stamped with the CPU 
> that it comes from.

See attached xm dmesg log in gzip'd form.  I cycled all processors
between highest and lowest frequency, with a change request
occuring for all processors every fifteen seconds.  The start 
of the sequence is marked in the log.

One thing that stands out is that although the dom0 notifier
event is firing for each core, Xen is running cpu_frequency_change
for cores 0 and 2.  The out of sync errors are occuring on
cores 1 and 3.  I'm looking into that now.

-Mark Langsdorf
Operating System Research Center
AMD

xen_revf_time-2.log.gz
Description: xen_revf_time-2.log.gz

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel