WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Niraj Tolia <ntolia@xxxxxxxxx>
Subject: RE: [Xen-devel] Problems with enabling hypervisor C and P-state control
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <7e45e2ac0810290832xe6e2d97h99d483aa19d73dfd@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <7e45e2ac0810220057w26b1ab45l8410c54346211d3f@xxxxxxxxxxxxxx> <7e45e2ac0810231649o7fd82c81ha09912cfa6a92b76@xxxxxxxxxxxxxx> <49582C73AC36CC4C8C6C42390304E81C092722D967@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810232145ob5f84bcs5c2aeb3e0b5de695@xxxxxxxxxxxxxx> <49582C73AC36CC4C8C6C42390304E81C0927508EC9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810271101h2a0177easea102be815888578@xxxxxxxxxxxxxx> <D8078B8B3B09934AA9F8F2D5FB3F28CE09395A5F8C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810271919k4b6b68f1u6f7309b6f1671b32@xxxxxxxxxxxxxx> <7e45e2ac0810271923q4372d167m107e878ba410f04a@xxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC2140C820C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810290832xe6e2d97h99d483aa19d73dfd@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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