This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Rik van Riel" <riel@xxxxxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 31 Aug 2007 10:42:08 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Langsdorf <mark.langsdorf@xxxxxxx>
Delivery-date: Thu, 30 Aug 2007 19:42:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46D6DB3F.3080104@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2FC4CDB.1504D%keir@xxxxxxxxxxxxx> <46D6DB3F.3080104@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfrFw31vuvSGdZTRFKPYpfObYtJawAXY3uQ
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
>From: Rik van Riel [mailto:riel@xxxxxxxxxx]
>Sent: 2007年8月30日 22:59
>Keir Fraser wrote:
>> 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
>> already in the Linux kernel. :-)
>Code duplication is bad.  It is the reason why Xen
>will (hopefully) go away in the long run.  Please do
>not propagate this horrible idea that all code should
>be copied around and have obsolete versions maintained
>The dom0 kernel is where the code already lives, so
>that code should be used.

My several points on this:

a) We shouldn't eliminate all possibilities in the start, and all experiments 
need to be done to see whether effort is worth for best power saving

b) Code duplication is definitely bad. But if finally xen-based governor is 
proved to be with best power saving cap, why not? Actually it's not that 
horrible as you said to copy all code. Xen just needs generic freq info 
and method to conduct freq change. All the parse and compatibility issue 
are still taken by dom0 with a new PV interface to report result to Xen.

c) Your patch in another mail is a good one to support on-demand driver 
within dom0. But there're several variants compared to native 
        * Idle time is not accurate since:
                - idle vcpu may still runs on other processors and then 
is not updated
                - the idle snapshot may change before returning to instruction 
after hypercall
        * latency information is inaccurate. On native, the latency basically 
reflects the time consumed on MSR write and de-facto freq change 
accurately. However on this case, the time between (dom0 issues 
WRMSR hypercall) and (Xen finally WRMSR) is even likely larger than 
sample ratio of on-demand driver, if vcpu switch happens in the middle.

        On-demand driver is fine-grained one which only works with 
transition latency <= 10ms. I believe that's a tuned value and it can't be 
always satisfied in virtualization environment. What does such variable 
'latency' make effect to final power saving of on-demand governor? 
Need data to see.

d) I guess final power saving of cpufreq (either approach) is not obvious, 
since average CPU utilization should be higher than native which is the 
goal of virtualization. C-state may be more interesting.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>