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

["Niraj Tolia" <ntolia@xxxxxxxxx>]

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

-- 
Niraj Tolia, Researcher, HP Labs
http://www.hpl.hp.com/personal/Niraj_Tolia/

xm.dmesg.out
Description: Binary data

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