[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Yu, Ke" <ke.yu@xxxxxxxxx>, Niraj Tolia <ntolia@xxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 24 Oct 2008 15:56:41 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 24 Oct 2008 00:57:09 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ack1k09vvX8kyUpuQteURFjSSiRC2wABxX6wAATWm9A=
  • Thread-topic: [Xen-devel] Problems with enabling hypervisor C and P-state control

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.