DomU Powernow question

DomU Powernow question

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]

Hi,

I recently posted the attached mail below to Keir Fraser.

I got an answer:

---- snip ----
The 'stale' frequency info in domU is harmless
---- snap ----


My question is, why the cpu frequency in dom0 ist not jumping to 2GHz,
if the cpu usage inside a domU is very high?

Second question: If in dom0, which value is showing the correct
information: the frequency or the bogomips? Normally the latter would
change, if the frequency changes. Not so in dom0? Why?

Kind regards
Christian


--- snip attached mail ---
Today I have recognized something interestin:

If I boot my Xen-box @ 2GHz, starting 2 DomUs at boottime, I can see
that the cpuinfo is showing:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 8
cpu MHz         : 2019.560
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow ts fid vid ttp
bogomips        : 4047.21

inside the DomUs, even the CPU has switched the frequency back to 800MHz.

If I do something like

while true; do ls -l | md5sum; done

in Dom0, the CPU frequency jumps @ 2GHz, while if doing the same inside
a DomU, the CPU still is @ 800MHz.

Now I thought, I would have to compile in cpufreq support into the DomU
kernel, but if I remove the "privileged" host option, the whole ACPI
powermanagement menu is away.

So, what can I change, to get this working correctly?

Maybe noone has tried something like this, but I think this is a little
bug, isn´t it?

There is something else: Normally, when the CPU frequency is @ 800 MHz,
the Bogomips are much less than 4000. But look at this:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 8
cpu MHz         : 800.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow ts fid vid ttp
bogomips        : 4021.05

If you think, I should post this to the xen-devel list, I first would
have to subscribe again.

But thanks in advance. Maybe you have some ideas on that.
---- snap ----

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





[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: DomU Powernow question

[Keir Fraser]

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.

> Second question: If in dom0, which value is showing the correct
> information: the frequency or the bogomips? Normally the latter would
> change, if the frequency changes. Not so in dom0? Why?

The code to recompute bogomips is in a file that is not compiled for 
Xen.

  -- Keir

Re: DomU Powernow question

[Christian Roessner]

[-- Attachment #1.1: Type: text/plain, Size: 712 bytes --]

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?


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




[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: Re: DomU Powernow question

[Petersson, Mats]

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Christian Roessner
> Sent: 15 June 2006 13:13
> To: Keir Fraser
> Cc: xen-devel@lists.xensource.com
> 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
> 
> 
> 
>