[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Create a linux-2.6.18-xen.hg Kernel with CPU_FREQ support


  • To: 'Carsten Schiers' <carsten@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 15 Jan 2009 09:17:03 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 14 Jan 2009 17:19:01 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acl2QFgKWTwYLcvFRPOWZ2u7Ww8WLQAbGyZA
  • Thread-topic: [Xen-devel] Create a linux-2.6.18-xen.hg Kernel with CPU_FREQ support

I see your concern and that's why I'd like to ask for more comments.
Change itself is easy anyway. Jan, how about your opinion on this
since you're from OSV? :-) I'm inclined to vote this, as we already 
change common acpi code with external control condition which is
designed to be neutral.

Thanks,
Kevin

>From: Carsten Schiers [mailto:carsten@xxxxxxxxxx] 
>Sent: Wednesday, January 14, 2009 8:03 PM
>
>Thanks, seems to work (still compiling). 
>
>Xen cpufreq (so I learnt) only supports AMD CPUs from Family 
>10 on. Which excludes,
>I guess, the majority of systems, although I have to admit 
>that normal Xen usage is
>not like mine for a home network.
>
>For those cases, I have understood cpufreq=dom0-kernel being 
>the standard, which 
>includes the need to have the CPU_FREQ part enabled. 
>
>I understand the problem and I am far from giving advice here, 
>but from a user's
>persepctive, it might not be necessary to implement code 
>control of possible misuse, 
>but maybe to control thru configuration what case your heading 
>at. Or at least a small 
>hint in the README would do... ;o).
>
>I am anyhow in trouble, as pre-Fam10 AMD CPUs lacks P-State 
>invariant TSCs, what is
>causing other trouble.
>
>Thanks,
>Carsten.
>
>----- Originalnachricht -----
>Von: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
>Gesendet: Mit, 14.1.2009 03:07
>An: 'Carsten Schiers' <carsten@xxxxxxxxxx> ; xen-devel 
><xen-devel@xxxxxxxxxxxxxxxxxxx>
>Betreff: RE: [Xen-devel] Create a linux-2.6.18-xen.hg Kernel 
>with CPU_FREQ support
>
>>From: Carsten Schiers
>>Sent: Wednesday, January 14, 2009 5:16 AM
>>
>>Excuse my missing knowledge, but how do I enable CPU_FREQ 
>support when 
>>building Xen 
>>hypervisor and especially the kernel from sources? When doing e.g. a
>>
>>  hg clone http://xenbits.xensource.com/xen-unstable.hg
>>  make world
>>
>>the resulting kernel will now create e.g. powernow-k8.ko. 
>>
>>When I do a
>>
>>  make linux-2.6-xen-prep
>>  cd build-linux-2.6.18-xen_x86_64
>>  make menuconfig
>>
>>all CPU_FREQ options are not accessable. 
>>
>>Thanks,
>>Carsten.
>>
>
>It's intentional since Xen itself supports cpufreq now. To avoid 
>dependency on dom0's CONFIG_CPU_FREQ and also intrusive 
>checks on whether external control is enabled in every linux
>cpufreq drivers, CPU_FREQ in dom0 is silented by default now.
>It's not a neat approach, but makes sense since xen controlled
>cpufreq is sure a better model. You can enable CPU_FREQ in
>dom0 manually though, by removing below dependency.
>
>(drivers/cpufreq/Kconfig)
> config CPU_FREQ
>        bool "CPU Frequency scaling"
>---->  depends on !PROCESSOR_EXTERNAL_CONTROL
>
>However once that dependency is removed, there's no automatic
>check to avoid confliction when dom0 and xen both want to
>control freq change, and then you should keep an eye yourself.
>
>One alternative to relax this limitation, is to move external control 
>check up from drivers to cpufreq common layer. Just several lines 
>change to block dom0 cpufreq when xen controlled method is 
>activated, but one drawback is in architecture-neutral files. Comments?
>
>Thanks,
>Kevin
>
_______________________________________________
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®.