RE: [Xen-devel] Re: DomU Powernow question

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Christian Roessner
> Sent: 15 June 2006 13:13
> To: Keir Fraser
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Re: DomU Powernow question
> 
> Hi,
> 
> Keir Fraser schrieb:
> > 
> > On 15 Jun 2006, at 11:38, Christian Roessner wrote:
> > 
> >> My question is, why the cpu frequency in dom0 ist not 
> jumping to 2GHz,
> >> if the cpu usage inside a domU is very high?
> > 
> > I'm not sure what triggers frequency changes in the dom0 
> kernel. It is
> > probably not accounting for work done in other domains. That would
> > likely require a new policy kernel module, or a user-space daemon to
> > gather stats from other domains.
> 
> As someone who really does not know anything about the 
> hypervisor, I may
> ask, why the scaling stuff is not done by the hypervisor?

As I've got about 300 unread e-mails, I don't know if this has been
answered or not (I couldn't see any answer with this subject in the new
several mails on my machine). Appologies if it's already been
explained... 

It COULD be managed by the Hypervisor, but it would cause some problems
to do that too... The "correct" solution is to have a new method of
controlling the speed that takes into account all the domains within the
system. It's not TERRIBLY hard to figure that out... But it does require
a bit of code-writing to gather the information and then adjust the
speed according to the current conditions. 

There is at least ONE good reason for NOT moving the code into the
hypervisor (which, when you look closely, turns into several reasons):
The hypervisor should be kept as small and simple as possible. 

So taking this apart, the ability to manipulate the CPU-speed requires
quite a bit in the form of "driver" code for the types of processors
that needs to be supported (this discussion is about AMD PowerNow!, but
other companies also have similar technologies, and the Hypervisor would
have to support those TOO - otherwise those companies would moan and
groan about no support - or their customers would...). 

The hypervisor itself also doesn't support loadable modules, so it would
be required to keep all of this code in the hypervisor at all times - or
implement loadable module support of course - which doesn't make it any
smaller... 

Finally, there's the problem of user-selectable policies - how to
determine what speed the processor needs to run at. This can be a
complex set of rules, taking all sorts of things into account (cpu-load
is the obvious one, but what about system temperature, battery vs.
plugged in power, daily variations, weekly variations, TV scheduling
[1], etc, etc). By using a Linux kernel that supports both loadable
modules and easy programming (for example through scripting languages,
such as perl and python or even shell-scripting) it can be quite easy to
set up a new set of rules for the power-policy. Doing so in the
hypvervisor itself would require that those are DEFINITELY programmed in
C, in the kernel-mode code, which makes the kernel bigger, and it's more
complex programming. 

[Note: I don't actually know how a policy is made in the curren cpufreq
managrement, it may well be a kernel module - however, it WOULD be
perfectly possible to create an interface that allows a selected
user-mode daemon written in just about ANY language to control the
device driver that ultimately sets the CPU speed in Linux - not so in
the hypervisor, unless you also make an interface for Dom0 to talk to
the Hypervisor, in which case the work ends up in Dom0 anyways... ;-)]

At the moment, the powernow driver is just running in Dom0, acting as if
Dom0 is the only domain in the system. Which may, or may not, be better
than not having any powernow support at all... In one respect it's
certainly better: it allows developers that use lap-tops for their daily
work to actually run the laptop at low power setting and thus be able to
run on batteries. Ok, so DomU's run slower too, but for those that want
this feature most, I don't think that's a limitation. 

For a server system, the requirement for PowerNow! and Xen would
definitely require the ENTIRE system to be taken into account, and the
current version is not good enough for this... 

[1] I mention TV scheduling, because I think web-servers may actually be
affected by certain types of TV coverage. I was, a long time ago, a
developer/SYSOP for a BBS-type system, and when we ran a "usage"
statistic for one particular month, we had a very noticable drop on one
two-hour period - which turned out to coincide with a particularly
high-profile film being on TV that particular day... 

--
Mats
> 
> 
> -- 
> Tel.: 0641-2097252, Mobil: 0171-3611230
> PGP: http://www.roessner-net.com/0x6B929997.asc
> 
> 
> 
> 


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