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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] Problems with enabling hypervisor C and P-state control
From: "Niraj Tolia" <ntolia@xxxxxxxxx>
Date: Mon, 27 Oct 2008 19:19:41 -0700
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Mon, 27 Oct 2008 19:20:18 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6Eg9CSCFPBjiyJHiGMhx0vJRKFmOGSASaQ9Y/e4T6i0=; b=aQmlicP/OXBbkUTNzD2aSpTTpr4Wa51w9e/zC+Difr3Ci1ZlwxtUJD+ImuJMuZElUJ h5rIxjLRRJAMTu5O1k/EiHSppoPEAvfFFM8TKdIgnpf5nUbNJC2L2LtqSq/B7KZ5eYyR LRWzPFl0hSyC2Ag1lLT0EEHEsEUmkOAINq9R4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ah2xhQbZ5V24fRSwVduoY6uwnsR8tM8+fu4ZrY45ngjC2TcluiKrk7VMExs5jCY0AB QMKwIy+bziEhiq4BLH/zu2eXUgEVqXL/y38ycX7yzzJvG9deLHxEOBlL30zQ0TEsZDO4 RJkfUVntHVz1XONuKYc+otJBJpr/BNj+MdqZ8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D8078B8B3B09934AA9F8F2D5FB3F28CE09395A5F8C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <49582C73AC36CC4C8C6C42390304E81C092722CF78@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810231649o7fd82c81ha09912cfa6a92b76@xxxxxxxxxxxxxx> <49582C73AC36CC4C8C6C42390304E81C092722D967@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810232145ob5f84bcs5c2aeb3e0b5de695@xxxxxxxxxxxxxx> <49582C73AC36CC4C8C6C42390304E81C0927508EC9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <7e45e2ac0810271101h2a0177easea102be815888578@xxxxxxxxxxxxxx> <D8078B8B3B09934AA9F8F2D5FB3F28CE09395A5F8C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

...

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

<Prev in Thread] Current Thread [Next in Thread>