41 messages in com.xensource.lists.xen-develRE: [Xen-devel] [PATCH] 1/2: cpufreq/...
FromSent OnAttachments
Mark Langsdorf29 Aug 2007 15:02 
Tian, Kevin29 Aug 2007 23:40 
Keir Fraser30 Aug 2007 02:30 
Tian, Kevin30 Aug 2007 02:45 
Keir Fraser30 Aug 2007 03:12 
Langsdorf, Mark30 Aug 2007 07:45 
Langsdorf, Mark30 Aug 2007 07:57 
Rik van Riel30 Aug 2007 07:58 
Keir Fraser30 Aug 2007 08:04 
Keir Fraser30 Aug 2007 08:08 
Rik van Riel30 Aug 2007 11:23.patch
Rik van Riel30 Aug 2007 13:56 
Tian, Kevin30 Aug 2007 18:19 
Tian, Kevin30 Aug 2007 19:41 
Tian, Kevin30 Aug 2007 19:42 
Jan Beulich31 Aug 2007 01:41 
Keir Fraser31 Aug 2007 02:22 
Keir Fraser31 Aug 2007 03:04 
Rik van Riel31 Aug 2007 06:50 
Tian, Kevin31 Aug 2007 08:09 
Keir Fraser31 Aug 2007 08:25 
Tian, Kevin31 Aug 2007 17:23 
Keir Fraser01 Sep 2007 04:06 
Tian, Kevin01 Sep 2007 06:30 
Keir Fraser01 Sep 2007 06:57 
Keir Fraser01 Sep 2007 07:12 
Tian, Kevin01 Sep 2007 07:13 
Tian, Kevin01 Sep 2007 07:18 
Tian, Kevin01 Sep 2007 07:22 
Keir Fraser01 Sep 2007 08:26 
Tian, Kevin01 Sep 2007 08:45 
Keir Fraser01 Sep 2007 09:41 
Tian, Kevin02 Sep 2007 21:24 
Rik van Riel04 Sep 2007 10:23 
xeb01 Oct 2007 01:29 
Keir Fraser01 Oct 2007 01:33 
xeb02 Oct 2007 05:56 
xeb02 Oct 2007 05:57 
xeb02 Oct 2007 05:59 
xeb02 Oct 2007 06:01 
xe...@mail.ru02 Oct 2007 06:05 
Subject:RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From:Langsdorf, Mark (mark@amd.com)
Date:08/30/2007 07:45:27 AM
List:com.xensource.lists.xen-devel

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. :-)

The advantage to doing it in the dom0 kernel is that the distributions have just switched from doing it in userspace, and thus have all their tools set up to do it in the kernel.

To me, it makes more sense to simplify the user interface, so that a native mode machine and a virtual machine uses the same tools. The end user shouldn't need to learn cpuspeed when running power management on a virtual machine host if the same computer uses ondemand when running a native mode kernel.

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.

powernow-k8 and the Intel SpeedStep equivalents are being maintained in preference to acpi-cpufreq. I don't think the code is obsolete or defunct.

-Mark Langsdorf Operating System Research Center AMD

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