Niraj, one more info here. From your log, cpus on your platform
are actually indexed by:
package 1 (0, 4, 8, 12)
package 2 (1, 5, 9, 13)
package 3 (2, 6, 10, 14)
package 4 (3, 7, 11, 15)
thus cpu0/1/2/3 actually indicates 1st core in each package,
instead of 4 cores in 1st package. :-)
Thanks,
Kevin
>-----Original Message-----
>From: Yu, Ke
>Sent: Friday, October 24, 2008 2:00 PM
>To: Niraj Tolia
>Cc: Xen Developers; Tian, Kevin; Liu, Jinsong
>Subject: RE: [Xen-devel] Problems with enabling hypervisor C
>and P-state control
>
>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
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home