WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel][PATCH 0/5] Add cpufreq pwr mgmt to Xen

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Subject: RE: [Xen-devel][PATCH 0/5] Add cpufreq pwr mgmt to Xen
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 13 May 2008 16:08:38 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Tue, 13 May 2008 01:09:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <482965E4.76E4.0078.0@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: <9D7649D18729DE4BB2BD7B494F7FEDC201400CB4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <482965E4.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci0ztaG9DvTj06+RgO/9W4+YhEJGAAABlDg
Thread-topic: [Xen-devel][PATCH 0/5] Add cpufreq pwr mgmt to Xen
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx] 
>Sent: 2008年5月13日 15:57
>
>Is it really necessary to further expand the code duplication 
>in Xen (instead
>of re-using the already existing code in dom0)? I was under 
>the impression
>that the latter had been the plan for as much as possible of 
>both Cx and Px
>handling... Jan
>

At least two reasons we see necessary to let Xen control freq
change directly, as discussed before:

a) Dom0 is itself a guest, which may be even scheduled out
between the point it makes decision and the point where Xen
traps the request to really update related MSRs. Also some
special measurement is required to ensure its ondemand
governor to be triggered within expected period. When whole
system is scaled up, above is likely to be more inaccurate.
While doing it in Xen can ensure fine-grained chk on real
processors, to fully utilize hardware fast-swtich technology.
This also allows for more governor experiments later like
to incorporates some virtualization specific information.

b) This releases dependency to requirement that dom0 vcpu
topolicy has to match physical one with affinity pushed.

Thanks,
Kevin

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