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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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
>within
>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.
>

Yep.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel