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] RFC: cpu frequency scaling

To: "Rik van Riel" <riel@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] RFC: cpu frequency scaling
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 26 Oct 2006 14:35:00 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 26 Oct 2006 05:39:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <453FD375.6080901@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acb4ergNrMs0UK6BS3msZ8JVGx7G3AAf4+VQ
Thread-topic: [Xen-devel] RFC: cpu frequency scaling
 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Rik van Riel
> Sent: 25 October 2006 22:13
> To: Keir Fraser
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] RFC: cpu frequency scaling
> 
> Keir Fraser wrote:
> 
> > Frequency changes in dom0, please. The 'small dom0' issue 
> is easily handled
> > -- create a driver domain to handle the frequency 
> management. Or move the
> > potentially resource-intensive processes in dom0 out to a domU 
> 
> or have a cpufreq "driver domain"...
> 
> OK, I'll take a look at how we can do these things.
> 
> I'm guessing the way to start would be having either userspace
> cpufreq code polling the hypervisor for CPU load, or have a
> drivers/cpufreq/cpufreq_ondemand-xen.c that gets the CPU load
> information from the hypervisor.
> 
> I'm guessing something like xentop already gets the right info
> from the hypervisor in a relatively efficient way, or some of
> the code in libvirt.
> 
> I'll dig around to see what code to hook into...

Consider that dual core CPU's (at least from AMD) will have to have the
same ("choose highest") CPU-speed both cores. This means that you need
to know which PHYSICAL CPU we're talking about. 

So you need to get the actual load of each physical CPU, then sort them
"per socket" and do any changes based on the highest (or lowest) load of
the actual socket. I'm not sure if all the necessary information is
available in Dom0 unless it's also running on all available cores -
however, neither am I sure if there's much point in pursuing the case
where all CPU's are NOT in Dom0... Allowing those cores that are not
Dom0-cores to have a driver-domain to control the speed would be
sensible solution - interesting things happen, however, if someone puts
core0 of a socket to Dom0, and Core1 of the same socket as DomU - you
can't really control that one even with a driver domain... 

--
Mats
> 
> -- 
> Who do you trust?
> The people with all the right answers?
> Or the people with the right questions?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



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

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