[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: Niraj Tolia <ntolia@xxxxxxxxx>
  • From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
  • Date: Thu, 30 Oct 2008 00:00:56 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
  • Delivery-date: Wed, 29 Oct 2008 09:01:26 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ack5243AuwNKZTPPTVu/TeWThr9ZXQAAzGPA
  • Thread-topic: [Xen-devel] Problems with enabling hypervisor C and P-state control

Niraj Tolia wrote:
> On Wed, Oct 29, 2008 at 2:02 AM, Liu, Jinsong <jinsong.liu@xxxxxxxxx>
> wrote: 
>> Niraj,
>> 
>> Any update about xen cpufreq at your platform? Does the patch work?
>> 
> 
> Hi Jinsong,
> 
> Yup, it does seem to work. I will let you know if I run into any
> other issues. 
> 
> Cheers,
> Niraj

Glad to see it work at your platform.
2 valuable results are:
- SW_ANY coordination has been tested in your platform and find a px statistic 
bug (I don't have this kind of platform);
- The correctness of cpufreq I/O control method has been tested in your 
platform (again, all my test platform is MSR control);
Thank you very much!

Jinsong

> 
>> Thanks,
>> Jinsong
>> 
>> Niraj Tolia wrote:
>>> On Mon, Oct 27, 2008 at 7:19 PM, Niraj Tolia <ntolia@xxxxxxxxx>
>>> wrote: 
>>>> On Mon, Oct 27, 2008 at 6:04 PM, Tian, Kevin <kevin.tian@xxxxxxxxx>
>>>> wrote:
>>>>>> From: Niraj Tolia [mailto:ntolia@xxxxxxxxx]
>>>>>> Sent: Tuesday, October 28, 2008 2:01 AM
>>>>>> 
>>>>>> On Thu, Oct 23, 2008 at 10:59 PM, Yu, Ke <ke.yu@xxxxxxxxx> wrote:
>>>>>>> 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.
>>>>>> 
>>>>>> I just applied the patch and while xenpm might be doing the right
>>>>>> thing, I am not completely sure. For example, if I launch a
>>>>>> single VCPU VM, pin it to a core, and launch a CPU intensive
>>>>>> task on it, ALL four cores on the socket are reported to switch
>>>>>> into P0. However, from what I understand about this processor
>>>>>> (Xeon E7330), only two of them should. Like vanilla Linux, the
>>>>>> other two should be able to operate at independent
>>>>>> voltage/frequency settings. Once again, I am not sure if this is
>>>>>> xenpm's fault or if the underlying frequency control code isn't
>>>>>> able to determine what  CPUs need to switch frequency at the
>>>>>> same time. 
>>>>>> 
>>>>> 
>>>>> Do you change any BIOS setting when comparing native Linux and
>>>>> Xen? From the xen dmesg you posted last time:
>>>> 
>>>> 
>>>> No, I did not change anything in the BIOS. However, when I run
>>>> vanilla Linux w/ cpufreqd, cpufreq-info will only list two cores
>>>> being tied together. This is with the 2.6.24-21 kernel provided
>>>> with Ubuntu 
>>>> 8.04.1.
>>>> 
>>>> # cpufreq-info
>>>> cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
>>>> Report errors and bugs to linux@xxxxxxxx, please.
>>>> analyzing CPU 0:
>>>>  driver: acpi-cpufreq
>>>>  CPUs which need to switch frequency at the same time: 0 4
>>>>  hardware limits: 1.60 GHz - 2.40 GHz
>>>>  available frequency steps: 2.40 GHz, 2.13 GHz, 1.87 GHz, 1.60 GHz
>>>>  available cpufreq governors: powersave, conservative, ondemand,
>>>>  userspace, performance current policy: frequency should be within
>>>>                  1.60 GHz and 1.60 GHz. The governor "powersave"
>>>>                  may decide which speed to use within this range.
>>>>  current CPU frequency is 1.60 GHz.
>>>> 
>>>> ...
>>>> 
>>> 
>>> I just noticed that cpufreq-info only lists 8 CPUs. Turns out that
>>> Ubuntu's kernels come with NR_CPUS = 8. So, you might be right. I
>>> will try and recompile a vanilla kernel tomorrow to see what
>>> happens. 
>>> 
>>> Cheers,
>>> Niraj
>>> 
>>>> Cheers,
>>>> NIraj
>>>> 
>>>>> ...
>>>>> (XEN)   _PSD: num_entries=5 rev=0 domain=1 coord_type=253
>>>>> num_processors=4 ... (XEN)   _PSD: num_entries=5 rev=0 domain=2
>>>>> coord_type=253 num_processors=4 ... (XEN)   _PSD: num_entries=5
>>>>> rev=0 domain=3 coord_type=253 num_processors=4 ... You can see
>>>>> that BIOS reports 4 processors in a dependent domain
>>>>> with a SW_ANY coordination type. It means that any cpu within
>>>>> given dependent domain changes freq, all the rest 3 cpus change
>>>>> too. 
>>>>> 
>>>>> Thanks,
>>>>> Kevin
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Niraj Tolia, Researcher, HP Labs
>>>> http://www.hpl.hp.com/personal/Niraj_Tolia/


_______________________________________________
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®.