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] cpufreq info propagation

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, <mark.langsdorf@xxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Subject: RE: [Xen-devel] cpufreq info propagation
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 23 Jul 2008 16:57:21 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 23 Jul 2008 01:59:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4887061D.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/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>
References: <4887061D.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjsnRoK4yzE2RNQQDWMRKyijGpBjQAAolHA
Thread-topic: [Xen-devel] cpufreq info propagation
>From: Jan Beulich
>Sent: 2008年7月23日 16:21
>
>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

thank you.

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

startup info is viable. But how fragile is the cmdline option?

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

If no existing usage already with dom0-controlled cpufreq, I agree 
that support is not necessary. The aim in original design when 
adding Xen cpufreq control, is to not break compatibility if any 
usage or release sticks to that style already.

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

If CPU_FREQ is off, error is returned when user tries to query
cpufreq information from Xen.

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

Not sure about your concern. Currently xen-controlled cpufreq isn't
enabled by default. User needs pass xen cmdline and also enable
dom0 CPU_FREQ. Once that's done, everything should work.
The interface you cited is not the one to report freq statistics to
user, which instead is the point to parse ACPI Px information which
will be further hypercalled to Xen later when extcnl controller is
notified. Statistics information is conveyed by sysctl interface by
far.

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

If user wants to disable cpufreq at all, a FREQCTL_none option is 
required.

Thanks,
Kevin

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