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

[Xen-devel] cpufreq info propagation

To: <mark.langsdorf@xxxxxxx>,"Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <jinsong.liu@xxxxxxxxx>
Subject: [Xen-devel] cpufreq info propagation
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 23 Jul 2008 09:21:17 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 23 Jul 2008 01:21:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Now that I finally got around to update our sources, I had a closer look at
those changes, and apart from stylistic issues on the Linux side (part of
which I may have asked for, but the result was somewhat overdone so
the code is hardly legible now - I've got a patch queued to streamline this
a little) I find it rather odd (fragile) that the who-is-in-charge information
gets propagated via a command line option rather than through the
startup info. I think this should be adjusted before 3.3 gets frozen.

Besides that I continue to wonder what significance the support for
Dom0-controlled cpufreq handling has now that Xen has the ability to
handle that. I ask this not the least because so far we disabled the
CPU_FREQ config option in our kernels, partly because of the unknown
status of all of the different low level drivers (powernow-k8 supposedly
works, acpi-cpufreq apparently might work, too, but most others I'm
pretty unclear about), but also because of the massive (and afaict
not upstream) changes to powernow-k8 (which we simply don't apply
at present) as well as due to the extra constraints that are required/
enforced when Dom0 is in charge.

In any case there is an open question for me as to how current status
is being reported to the user (at least in Dom0) on the current CPU
frequency in use when CPU_FREQ is configured off (and I have to
admit that while I didn't try it, I suspect it doesn't even work when
CPU_FREQ is on - this is because the apparently only reporting
function, processor_extcntl_get_performance(), is being called
exclusively in the context of acpi_processor_start()). With that I
wonder how I would be able to determine whether the code works
at all.

As a minor observation, I also find the naming vs. meaning of the
FREQCTL_none enumerator misleading - shouldn't this rather be
FREQCTL_xen?

Jan


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