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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Niraj,

Any update about xen cpufreq at your platform? Does the patch work?

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