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

RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Mark Langsdorf" <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 30 Aug 2007 17:45:39 +0800
  • Delivery-date: Thu, 30 Aug 2007 03:04:41 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToA==
  • Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年8月30日 17:31
>On 30/8/07 07:41, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> a) Current approach is simple to let Dom0 conduct frequency
>> change. That should be OK in the start, but at the same time we
>> should also consider the on-demand governor within Xen itself.
>> Xen can always get first-hand data about domain status, while
>> dom0 (either user-level or in-kernel) can't achieve in time. Fine-
>> grained frequency change is more likely to be achieved within
>> Xen directly.
>Personally I'm a fan of doing it in dom0 userspace, although doing it
>Xen can also be argued for. Doing it in dom0 kernel doesn't seem very
>attractive apart from the obvious pragmatic advantage that all the code is
>already in the Linux kernel. :-)

Sure, some experiment can be done later to compare dom0 userspace 
and in-xen governor. Agree that in-kernel dom0 approach is not 
charming because anyway it needs help from either user-level or xen 
for global view.

Actually finally we may take both. Xen takes simple heuristic policy 
with user-level governor to adjust with more complex and flexible 
policies based on domain behaviors. :-)

>If we're doing it in the Linux kernel, I don't see much point in hacking up
>the defunct powernow (or equivalent Intel) code. Why not fix the generic
>acpi-cpufreq.c? That is supposed to work on any modern CPU. I'm not
>sure the
>2.6.18 version is new enough, but I'd rather see a backported and fixed
>version of that file, rather than bother to maintain modified versions of
>obsolete source files.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.