[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |