RE: [Xen-devel] Problems with enabling hypervisor C and P-state control

["Yu, Ke" <ke.yu@xxxxxxxxx>]

After discussing with Jinsong, we got the root cause. You are right, this is 
xen pm statistics logic issue. when the coordination type is SW_ANY, we only 
record the first CPU cpufreq change, the other 3 cores within the same 
dependency domain is ignored, so you only see one core changes every dependency 
domain. 

The attached patch fix  this issue. could you please have a try? If it works in 
your platform, we will send out for applying in upstream.

Best Regards
Ke

Niraj Tolia wrote:
> On Thu, Oct 23, 2008 at 8:14 PM, Yu, Ke <ke.yu@xxxxxxxxx> wrote:
>> Niraj Tolia wrote:
>>> 
> 
> [snip]
> 
>>> 
>>> 
>>> Second, when I look at the P-state output (shown below), xenpm shows
>>> that the lowest P-state is only set on the first socket (this is a
>>> quad-core, quad-socket system). However, I have a feeling that this
>>> might be a problem with displaying the data rather than the
>>> underlying logic. Any ideas? 
>>> 
>>> # xenpm | grep '*'
>>> *P3                  : freq       [1599 MHz]
>>> *P3                  : freq       [1599 MHz]
>>> *P3                  : freq       [1599 MHz]
>>> *P3                  : freq       [1599 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>>> *P0                  : freq       [2398 MHz]
>> 
>> This seems a bug. From the above info, I can not decided if it is
>> xenpm issue or xen cpufreq issue. could you please provide more
>> info, e.g. - xen boot log (with loglvl=info), so that we can see if
>> cpufreq driver is initialized in all cpus  
> 
> The output 'xm dmesg' is attached but is truncated as the buffer
> overflowed. However, there should be enough information to show that
> cpufreq drivers are initialized for most cpus.
> 
>> - xentrace date on Px state, so that we can see if the Px transition
>> really happened. 
>> 
> 
> The below output was displayed when I started and stopped CPU
> intensive tasks on a system where xenpm initially listedthe first four
> cores being in P3 and the rest in P0.
> 
> cat tmp.out | xentrace_format
> /home/ntolia/src/xen-unstable.hg/tools/xentrace/formats  | grep -i
> freq
> 
> CPU3  635322726837 (+ 1898604)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU0  637123663233 (+ 1816488)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU0  637365505221 (+ 1826208)  cpu_freq_change [ 2398MHz -> 1599MHz ]
> CPU1  637423814277 (+ 1799946)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU2  637449731748 (+ 1748628)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU2  637691500107 (+ 1816884)  cpu_freq_change [ 2398MHz -> 1599MHz ]
> CPU0  637847441253 (+ 1932336)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU1  637905760983 (+ 1819935)  cpu_freq_change [ 2398MHz -> 1599MHz ]
> CPU2  637933222818 (+ 1707120)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU1  638147682630 (+ 1906677)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> CPU0  639049514238 (+ 1859544)  cpu_freq_change [ 2398MHz -> 2132MHz ]
> CPU0  639531387018 (+ 1844451)  cpu_freq_change [ 2132MHz -> 2398MHz ]
> CPU1  639589748679 (+ 1772361)  cpu_freq_change [ 2398MHz -> 1599MHz ]
> CPU1  639831560877 (+ 1797507)  cpu_freq_change [ 1599MHz -> 2398MHz ]
> 
> 
> I would be happy to help test patches on this system.
> 
> Cheers,
> Niraj

px-xen-pxstat-update.patch
Description: px-xen-pxstat-update.patch

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