[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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... 

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.